├── .github
    ├── CODEOWNERS
    ├── PULL_REQUEST_TEMPLATE.md
    └── workflows
    │   ├── gh-pages.yml
    │   └── tidy.yml
├── .gitignore
├── .pr-preview.json
├── CONTRIBUTING.md
├── LICENSE.md
├── README.md
├── custom-schemes.md
├── explainer.md
├── horizontal-reviews
    └── security-privacy.md
├── index.html
├── proposals
    ├── digital-credential-proposal.md
    ├── digital-credentials-2-proposal.md
    ├── identity-credential-proposal.md
    ├── mobile-document-request-api-proposal.md
    ├── navigator-identity-proposal.md
    └── structure.svg
├── resources
    ├── DigitalCredentialsAPI-Layering-v20240301.pdf
    └── IdentityCredentialAPI-Layering-2023.pdf
├── tidyconfig.txt
└── w3c.json


/.github/CODEOWNERS:
--------------------------------------------------------------------------------
1 | /.github/ @marcoscaceres
2 | index.html @w3c-fedid/dc-editors
3 | 


--------------------------------------------------------------------------------
/.github/PULL_REQUEST_TEMPLATE.md:
--------------------------------------------------------------------------------
 1 | Closes #???
 2 | 
 3 | The following tasks have been completed:
 4 | 
 5 | - [ ] Modified Web platform tests (link)
 6 | 
 7 | Implementation commitment:
 8 | 
 9 | - [ ] WebKit (link to issue)
10 | - [ ] Chromium (link to issue)
11 | - [ ] Gecko (link to issue)
12 | 
13 | Documentation and checks
14 | 
15 | - [ ] Affects privacy
16 | - [ ] Affects security
17 | - [ ] Pinged MDN
18 | - [ ] Updated Explainer
19 | - [ ] Updated digitalcredentials.dev
20 |  
21 | 


--------------------------------------------------------------------------------
/.github/workflows/gh-pages.yml:
--------------------------------------------------------------------------------
 1 | # Simple workflow for deploying static content to GitHub Pages
 2 | name: Deploy static content to Pages
 3 | 
 4 | on:
 5 |   # Runs on pushes targeting the default branch
 6 |   push:
 7 |     branches:
 8 |       - main
 9 |     paths:
10 |       - 'index.html'
11 |       - 'w3c.json'
12 | 
13 |   # Allows you to run this workflow manually from the Actions tab
14 |   workflow_dispatch:
15 | 
16 | # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
17 | permissions:
18 |   contents: read
19 |   pages: write
20 |   id-token: write
21 | 
22 | # Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
23 | # However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
24 | concurrency:
25 |   group: "pages"
26 |   cancel-in-progress: false
27 | 
28 | jobs:
29 |   # Single deploy job since we're just deploying
30 |   deploy:
31 |     environment:
32 |       name: github-pages
33 |       url: ${{ steps.deployment.outputs.page_url }}
34 |     runs-on: ubuntu-latest
35 |     steps:
36 |       - name: Checkout
37 |         uses: actions/checkout@v4
38 |       - name: Setup Pages
39 |         uses: actions/configure-pages@v5
40 |       - name: Upload artifact
41 |         uses: actions/upload-pages-artifact@v3
42 |         with:
43 |           # Upload entire repository
44 |           path: '.'
45 |       - name: Deploy to GitHub Pages
46 |         id: deployment
47 |         uses: actions/deploy-pages@v4
48 | 


--------------------------------------------------------------------------------
/.github/workflows/tidy.yml:
--------------------------------------------------------------------------------
 1 | name: Tidy document
 2 | on:
 3 |   workflow_dispatch: {}
 4 |   push:
 5 |     branches:
 6 |       - main
 7 |     paths:
 8 |       - 'index.html'
 9 | 
10 | jobs:
11 |   tidy:
12 |     name: Tidy up
13 |     runs-on: macos-latest
14 |     steps:
15 |       - uses: actions/checkout@v4
16 |       - run: brew install tidy-html5
17 |       - run: tidy -config tidyconfig.txt -o index.html index.html
18 |       - uses: peter-evans/create-pull-request@v6
19 |         with:
20 |           title: "Tidied up document using tidy-html5"
21 |           commit-message: "chore: tidy up index.html"
22 |           branch: html-tidy
23 | 


--------------------------------------------------------------------------------
/.gitignore:
--------------------------------------------------------------------------------
 1 | # Created by https://www.toptal.com/developers/gitignore/api/macos,windows
 2 | # Edit at https://www.toptal.com/developers/gitignore?templates=macos,windows
 3 | 
 4 | ### macOS ###
 5 | # General
 6 | .DS_Store
 7 | .AppleDouble
 8 | .LSOverride
 9 | 
10 | # Icon must end with two \r
11 | Icon
12 | 
13 | 
14 | # Thumbnails
15 | ._*
16 | 
17 | # Files that might appear in the root of a volume
18 | .DocumentRevisions-V100
19 | .fseventsd
20 | .Spotlight-V100
21 | .TemporaryItems
22 | .Trashes
23 | .VolumeIcon.icns
24 | .com.apple.timemachine.donotpresent
25 | 
26 | # Directories potentially created on remote AFP share
27 | .AppleDB
28 | .AppleDesktop
29 | Network Trash Folder
30 | Temporary Items
31 | .apdisk
32 | 
33 | ### macOS Patch ###
34 | # iCloud generated files
35 | *.icloud
36 | 
37 | ### Windows ###
38 | # Windows thumbnail cache files
39 | Thumbs.db
40 | Thumbs.db:encryptable
41 | ehthumbs.db
42 | ehthumbs_vista.db
43 | 
44 | # Dump file
45 | *.stackdump
46 | 
47 | # Folder config file
48 | [Dd]esktop.ini
49 | 
50 | # Recycle Bin used on file shares
51 | $RECYCLE.BIN/
52 | 
53 | # Windows Installer files
54 | *.cab
55 | *.msi
56 | *.msix
57 | *.msm
58 | *.msp
59 | 
60 | # Windows shortcuts
61 | *.lnk
62 | 
63 | # End of https://www.toptal.com/developers/gitignore/api/macos,windows


--------------------------------------------------------------------------------
/.pr-preview.json:
--------------------------------------------------------------------------------
1 | {
2 |   "src_file": "index.html",
3 |   "type": "respec",
4 |   "params": {
5 |     "force": 1
6 |   }
7 | }
8 | 
9 | 


--------------------------------------------------------------------------------
/CONTRIBUTING.md:
--------------------------------------------------------------------------------
 1 | # Digital Credentials: Federated Identity on the Web Working Group
 2 | 
 3 | This repository is being used for work in the W3C Federated Identity on the Web Working Group, governed by the [W3C Patent Policy](http://www.w3.org/Consortium/Patent-Policy-20040205/) and
 4 | [Spftware and Document License](https://www.w3.org/copyright/software-license-2023/). To contribute, you must 
 5 | either participate in the relevant W3C Working Group or make a [non-member patent licensing
 6 |  commitment](https://www.w3.org/policies/process/#contributor-license).
 7 | 
 8 | 
 9 | If you are not the sole contributor to a contribution (pull request), please identify all
10 | contributors in the pull request comment.
11 | 
12 | To add a contributor (other than yourself, that's automatic), mark them one per line as follows:
13 | 
14 | ```
15 | +@github_username
16 | ```
17 | 
18 | If you added a contributor by mistake, you can remove them in a comment with:
19 | 
20 | ```
21 | -@github_username
22 | ```
23 | 
24 | If you are making a pull request on behalf of someone else but you had no part in designing the
25 | feature, you can remove yourself with the above syntax.
26 | 


--------------------------------------------------------------------------------
/LICENSE.md:
--------------------------------------------------------------------------------
 1 | All Reports in this Repository are licensed by Contributors
 2 | under the
 3 | [W3C Software and Document License](http://www.w3.org/Consortium/Legal/2015/copyright-software-and-document).
 4 | 
 5 | Contributions to Specifications are made under the
 6 | [W3C CLA](https://www.w3.org/community/about/agreements/cla/).
 7 | 
 8 | Contributions to Test Suites are made under the
 9 | [W3C 3-clause BSD License](https://www.w3.org/Consortium/Legal/2008/03-bsd-license.html)
10 | 
11 | 


--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
 1 | # Digital Credentials
 2 | 
 3 | 📄 [Digital credentials explainer](explainer.md) and [draft spec](https://w3c-fedid.github.io/digital-credentials/).
 4 | 
 5 | This draft (migrated to the Federated Identity on the Web WG in April 2025) specifies an API for user agents that would mediate access to, and representation of, verifiably-issued digital credentials.
 6 | 
 7 | These identities can range from government-issued documents, such as driver's licenses and passports, to start with, to other credential types, potentially in the future.
 8 | 
 9 | [Digital Credentials](https://w3c-fedid.github.io/digital-credentials/) builds upon [Credential Management](https://www.w3.org/TR/credential-management-1/) to enable the secure and private exchange of digital identity information. It facilitates authenticated interactions by representing digital credentials through the `DigitalCredential` interface, which embodies verifiable claims about an individual's identity.
10 | 
11 | ## Scope
12 | 
13 | This project covers the requesting mechanisms for digital credentials, including secure presentation aspects. It does not yet encompass the issuance process for establishing a digital identity nor UI/UX considerations beyond privacy aspects related to data protection during the request process.
14 | 
15 | ## Trying out the API
16 | 
17 | **🚧 Note: The API is still extremely unstable and undergoing a lot of changes (almost daily!). 🚧**
18 | 
19 | However, if you want to try it out:
20 | 
21 | - [Try out the API in Chrome](https://digitalcredentials.dev/docs/requirements/)
22 | 
23 | ## Contributing
24 | 
25 | This is a draft (migrated to the Federated Identity on the Web WG in April 2025) under development. Contributions, feedback, and discussions are highly encouraged to refine and enhance the API specification.
26 | Join the WG to help us in shape the future of digital identity management on the web.
27 | 
28 | ### Weekly Meetings
29 | 
30 | - Slack ["fedid-wg"](https://app.slack.com/client/T010EGK9PQE/C06RR5RQUDT) in W3C Community instance.
31 | - [Meeting notes](https://github.com/w3c-fedid/meetings)
32 | - [Calendar](https://www.w3.org/groups/wg/fedid/calendar/)
33 | - [Agenda doc](https://docs.google.com/document/d/1Sq9tjh4Hv887Mzjoor-ZauXJ1glq6MCdjTsyUYNHjWA/)
34 | 
35 | ## Initial proposals
36 | 
37 | The initial proposals have been moved to the proposals folder. They are still available as historical references.
38 | 


--------------------------------------------------------------------------------
/custom-schemes.md:
--------------------------------------------------------------------------------
 1 | # Concerns with custom schemes for identity presentment
 2 | 
 3 | Existing specifications like [OpenID4VP](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-wallet-invocation) and [ISO 18013-7](https://www.iso.org/standard/82772.html) currently define the use of custom URL schemes (eg. `openid4vp:` and `mdoc:`) to enable verifier websites to invoke holder (wallet) applications. This approach works in some scenarios, but has a number of problems we aim to solve by designing a browser API which can replace the use of custom URL schemes in these specifications. This DRAFT document aims to outline the questions and concerns with the use of custom URL schemes for identity presentment in order to provide more detail on potential benefits of a dedicated browser API.
 4 | 
 5 | ## Can wallets reliably determine their invoker?
 6 | 
 7 |    - Android and iOS offer no facility to determine the web origin which triggered a navigation to a custom URL scheme.
 8 |    - This seems to increase the opportunity for attacks such as replay attacks, man-in-the-middle attacks and phishing. It also seems to limit the opportunity for abuse detection and prevention.
 9 |    - A browser API can securely pass the requesting origin on to the wallet so that the wallet can know with confidence what origin the user was on when the request was initiated.
10 |    
11 | ## Can wallets limit requests to secure contexts?
12 | 
13 |    - If a user uses a website via http (not https) and it invokes a custom scheme, it's possible that an attacker with access to the network could eavesdrop on or even modify the request (such as by replacing the verifier's public key with their own).
14 |    - A browser API could (and almost certainly should) take the position that it will function only within the context of a secure context (https).
15 | 
16 | ## User experience concerns
17 | 
18 | ### What is the user experience when the wallet has completed?
19 | 
20 |    - After launching an application via a custom URL scheme, mobile operating systems don't provide a mechanism for switching back to the invoking application / browser tab.
21 |    - Wallet applications may choose to start a new navigation to a new web page to complete the journey, but that can be slow and jarring, may not open in the same browser the user was originally using, and leaves a "dead tab" behind.
22 |    - Alternatively wallet applications could rely on the user manually switching back to the browser application they were in, but that can be hard to communicate to users and risks the web page being reloaded due to mobile operating system memory management facilities, and therefore risks user abandomment.
23 |    - A browser API can ensure the original webpage remains resident during the wallet application and seamlessly return to it with the credential data.
24 | 
25 | ### What is the user experience when multiple wallet apps are installed?
26 | 
27 |    - When multiple Android applications register for the same custom URL scheme, the operating system presents the user with a picker every time that scheme is invoked. Even if the verifier provides the user with appropriate context, a user may have trouble remembering which application has which credentials and so be more likely to cancel or fail the request.
28 |    - On iOS, when multiple applications are installed that register for the same custom URL scheme, the behavior is [undefined](https://stackoverflow.com/questions/13130442/multiple-apps-with-the-same-url-scheme-ios). At present, one indeterminate wallet will be invoked without any indication that other wallets were available.
29 | 
30 | ### What is the user experience when no wallet app is installed or when the user cancels wallet invocation?
31 | 
32 |    - Browsers generally silently ignore navigation to URL schemes with no handler installed. This likely means a website cannot distinguish between nothing happening while waiting for a wallet to process a request and nothing happening because no wallet app is installed.
33 |    - Additionally browsers on Android and iOS often offer the user the choice of whether or not to invoke an application for a custom URL scheme navigation (even if there is only one such app). The user canceling at this stage is also indistinguishable from no valid application being installed.
34 |    - A browser-based API could show the user some meaningful error message when no relevant wallets are installed.
35 | 
36 | ### What is the user experience on a desktop operating system?
37 | 
38 |    - Most wallet applications exist only as mobile applications, and users are generally reluctant if not unable (due to enterprise security settings, for instance) to install native applications on desktop operating systems. What fallback will flows relying on custom URL schemes provide for users of desktop operating systems?
39 |    - A browser-based API can potentially provide low-friction integration between a desktop browser and a wallet application running on a mobile phone or a website that provides an in-browser wallet experience on the same device.
40 | 
41 | ### Friction and app switching
42 | 
43 |    - Opening a custom URL scheme will launch an entirely new application, which can be jarring for users, taking them out of the flow of the journey they were trying to complete on a website. This risks abandonment, and so is a disincentive for verifiers to invoke the flow.
44 |    - A browser API could integrate with the operating system to provide a less jarring wallet overlay on top of the web page, keeping the user feeling in flow with the site's experience.
45 | 
46 | ## What are the privacy implications of a wallet accepting custom schemes?
47 | 
48 |    - [Android aims](https://developer.android.com/training/package-visibility) to keep the list of installed applications private from other applications, but this capability is reduced for applications which handle arbitrary intents like custom URL schemes. By registering to support custom URL schemes, a wallet application may effectively be leaking PII (such as the user's likely citizenship status or state of residency) to other applications on the device.
49 |    - A purpose-built OS API for wallet invocation (on top of which a browser API would be built) can avoid any such information leakage.
50 | 
51 | ## How can users be assured that they have control over where their personal information is shared?
52 | 
53 |    - A buggy or poorly designed wallet application may store or transmit sensitive information about the user (such as which website(s) the user was visiting and when) without necessarily ensuring the user has provided informed consent. Malicious websites may exploit bugs in wallets to cause them to leak information without requiring any consent from the user. Wallets and credentials may come from any source, but users will expect their operating systems and browsers to protect their privacy from buggy or malicious wallet applications.
54 | 
55 | <hr>
56 | 
57 | Due to these concerns, Google Chrome has [proposed](https://groups.google.com/a/chromium.org/g/blink-dev/c/wcCrcMTELS0/m/ZSPxAT0LAgAJ) blocking website access to specific high-risk custom URL schemes, and instead invoking wallets via a browser-mediated API. Anyone interested in contributing to the design of such an API is encouraged to join the W3C's [Web Incubator Community Group](https://www.w3.org/community/wicg/) and contribute to the [Identity Credential proposal](https://github.com/WICG/identity-credential/). While websites will likely always be able to communicate directly with wallet applications in some fashion, it is the group's hope that a browser-based API can be designed which is a better option for wallets and verifiers, and which also provides users with confidence in having their sensitive identity information potentially exposed to websites they visit.
58 | 


--------------------------------------------------------------------------------
/explainer.md:
--------------------------------------------------------------------------------
  1 | # Digital Credentials API
  2 | 
  3 | Government recognized digital credentials (e.g. driver’s licenses) are being increasingly utilized on the web. We propose a deliberate and flexible API to enable browsers to continuously improve the balance of benefits and risks for users and the entire online community.
  4 | 
  5 | # Why?
  6 | 
  7 | Government-recognized documents play a big and constructive role in society (e.g., drivers licenses, passports, etc.). Increasingly, with the movement of government and financial services online, and regulation (e.g. [eIDAS](https://en.wikipedia.org/wiki/EIDAS) and various [age verification regulations](https://en.wikipedia.org/wiki/Age_verification_system)), these paper-based documents are gaining digital counterparts
  8 | 
  9 | Along with all of their potential from the physical world, the presentation of government recognized  digital credentials also brings their associated risks of abuse, such as the potential for an increase in [surveillance](https://github.com/w3cping/credential-considerations/blob/main/credentials-considerations.md#no-phoning-home), [censorship](https://github.com/w3cping/credential-considerations/blob/main/risks.md#censorship-and-reduction-in-access-to-free-information), [discrimination](https://github.com/w3cping/credential-considerations/blob/main/credentials-considerations.md#free-expression), and intrusion to the online world.
 10 | 
 11 | The most recent online presentation protocols (e.g. [OpenID4VP](https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html)) and regulations (e.g. eIDAS) were designed around a Web that lacked the intentional support for such a critical task; depending instead on general purpose primitives such as custom schemes. Unfortunately, the use of [custom schemes](https://github.com/WICG/digital-identities/blob/main/custom-schemes.md#concerns-with-custom-schemes-for-identity-presentment) left us with two problems:
 12 | 
 13 | Because custom schemes can be largely opaque to user agents, they substantially limit the user agent’s ability to exercise its agency in reducing the risk of abuse. Users rely on their browser to help provide transparency and control over the use of their data. From the subtle, like providing [UI](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/url_display_guidelines/url_display_guidelines.md) [cues](https://blog.chromium.org/2023/05/an-update-on-lock-icon.html) as to the privacy and security risks of various operations. To the more severe, like [warning](https://blog.google/products/chrome/google-chrome-safe-browsing-real-time/) about interacting with known phishing sites.
 14 | 
 15 | Even in highly-regulated and non-abusive use cases (e.g. eIDAS), custom schemes have  [security](https://github.com/WICG/digital-identities/blob/main/custom-schemes.md#can-wallets-limit-requests-to-secure-contexts) and [privacy](https://github.com/WICG/digital-identities/blob/main/custom-schemes.md#what-are-the-privacy-implications-of-a-wallet-accepting-custom-schemes) risks, as well as a series of suboptimal [user experiences. We posit that these limitations](https://github.com/WICG/digital-identities/blob/main/custom-schemes.md#user-experience-concerns) can be addressed by a purpose-built browser API. While some have reasonably argued that these limitations will slow-down and limit the deployment (and so, the abuse) of such technology, it seems more advantageous  to rely on intentional design choices to manage this tradeoff than such accidents. 
 16 | 
 17 | In the pursuit of establishing a standard for web-based identity sharing, it is paramount that we not only strive for ease of use but also exercise utmost caution to uphold high standards of security and privacy. This is essential to safeguard users from potential identity theft and ensure they are fully informed about the implications of online identity sharing before providing their consent. We firmly believe that relying on a browser API and the mobile platform is the most reliable approach for identity digital credentials to be shared securely online.
 18 | 
 19 | 
 20 | # What?
 21 | 
 22 | First we must acknowledge, architecturally, that this is a rapidly evolving space with a large number of moving parts at various different levels of maturity. Users, regulations (e.g. eIDAS), wallets, verifiers, issuers, formats (e.g. [ISO mDocs](https://www.iso.org/obp/ui/en/#iso:std:iso-iec:18013:-5:ed-1:v1:en) and [W3C VCs](https://verifiablecredentials.dev/), just to name a few) and protocols (e.g. [OpenID4VP](https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html), ISO REST’s API, [VC API](https://github.com/w3c-ccg/vc-api)), operating systems and browsers (e.g. evolving mitigation strategies, for [example](https://docs.google.com/document/d/1L68tmNXCQXucsCV8eS8CBd_F9FZ6TNwKNOaFkA8RfwI/edit#heading=h.8gq5f7p3it8q)) are all still in various stages of formation and need the space and autonomy to evolve efficiently.
 23 | 
 24 | So, to the extent that we can, it is important to leave levels of indirections that would allow us to extend the API without having to redesign it. Sometimes, extensibility, autonomy (eg. of different standards bodies) and the ability/incentives of ecosystem adoption are in tension with other goals, such as the user’s privacy and security, so we often have to find a good and principled balance (e.g. more often than not, [users first, developers second, and browser engines third](https://www.w3.org/TR/design-principles/#priority-of-constituencies), guides our choices at the W3C). 
 25 | 
 26 | To balance this tension we propose an API with the following key properties:
 27 | 
 28 | - By separating the act of requesting from the specific protocol, we can enable flexibility and adaptability in both the protocol and credential formats. This way, the pace of changes in browsers won't hinder progress or block new developments.
 29 | - Require request transparency, enabling user-agent inspection for risk analysis
 30 | - Assume response opacity (encrypted responses), enabling verifiers and holders to control where potentially sensitive PII is exposed
 31 | - Websites cannot access any information without user interaction. This API ensures that sites cannot silently query for digital credentials or communicate with wallet providers without the user's active participation and confirmation of each action.
 32 | 
 33 | At its core, the API is designed for a website ("verifier") to [transparently](https://github.com/w3cping/credential-considerations/blob/main/credentials-considerations.md#in-context-explanations) request the [selective disclosure](https://github.com/w3cping/credential-considerations/blob/main/credentials-considerations.md#selective-disclosure) of attributes from (issued) digital credentials that were provisioned - ahead of time - to wallets ("holders"), in a manner that is seamlessly compatible with existing architectural choices (such as [OpenID4VP integration](https://github.com/openid/OpenID4VP/issues/125)).
 34 | 
 35 | Here is an example of how the  the API might be used in practice:
 36 | 
 37 | The API needs to be initiated through a user gesture, such as a button click:
 38 | 
 39 | ```html
 40 | <button onclick="requestCredential()">Request Driver's license<button>
 41 | ```
 42 | 
 43 | 
 44 | ```javascript
 45 | async function requestCredential() {
 46 | 
 47 |   // Check for Digital Credentials API support
 48 |   if (typeof window.DigitalCredential !== 'undefined') {
 49 |     
 50 |     try {
 51 |       
 52 |       // These parameters are typically fetched from the backend.
 53 |       // Statically defined here for protocol extensibility illustration purposes.
 54 |       const oid4vp = {
 55 |         protocol: "oid4vp", // An example of an OpenID4VP request to wallets. // Based on https://github.com/openid/OpenID4VP/issues/125
 56 |         data: {
 57 |           nonce: "n-0S6_WzA2Mj",
 58 |           presentation_definition: {
 59 |           //Presentation Exchange request, omitted for brevity
 60 |           },
 61 |         },
 62 |       };
 63 | 
 64 |       // create an Abort Controller
 65 |       const controller = new AbortController();
 66 | 
 67 |       // Call the Digital Credentials API using the presentation request from the backend
 68 |       let dcResponse = await navigator.credentials.get({
 69 |         signal: controller.signal,
 70 |         mediation: "required",
 71 |         digital: {
 72 |           requests: [ oid4vp ]
 73 |         }
 74 |       });
 75 | 
 76 |       // Send the encrypted response to the backend for decryption and verification
 77 |       // Ommitted for brevity
 78 | 
 79 |     } catch (error) {
 80 |       console.error('Error:', error);
 81 |     }
 82 |   } else {
 83 |     
 84 |     // fallback scenario, illustrative only
 85 |     alert("The Digital Credentials API is not supported in this browser.")
 86 |   }
 87 | };
 88 | ```
 89 | 
 90 | > Example from: https://digitalcredentials.dev/docs/verifier-site/requesting-cred
 91 | 
 92 | You can read a more detailed and technical description of the API in the [specification draft](https://w3c-fedid.github.io/digital-credentials/).
 93 | 
 94 | ### Using the API from another origin
 95 | 
 96 | The specification allows usage of the API from a remote/third-party origin via the "digital-credentials-get" Permissions Policy. This is useful for scenarios where a website wants to request digital credentials from a wallet provider that is hosted on a different origin. The Permissions Policy can be set on an iframe that embeds the website that wants to use the API. Here is an example of how the Permissions Policy can be set on an iframe:
 97 | 
 98 | ```HTML
 99 | <iframe allow="digital-credentials-get"></iframe>
100 | ```
101 | 
102 | ## Horizontal reviews
103 | 
104 | * [Security and privacy TAG Questionnaire](horizontal-reviews/security-privacy.md)
105 | 
106 | # Alternatives Considered
107 | 
108 | There are many alternatives that were considered, most notably:
109 | 
110 | - [Do nothing](https://github.com/w3cping/credential-considerations/blob/main/risks.md#the-consequences-of-a-failure-to-act-are-as-valid-as-those-of-acting) (the intentional status quo in browsers for the past several years)
111 | - Various different [API proposals](https://github.com/WICG/digital-identities/tree/main/proposals): [an mDoc-specific API](https://github.com/WICG/digital-identities/blob/main/proposals/mobile-document-request-api-proposal.md), [extending the Credential Management API](https://github.com/WICG/digital-identities/blob/main/proposals/digital-credential-proposal.md), [extending the FedCM API](https://github.com/WICG/digital-identities/blob/main/proposals/identity-credential-proposal.md) and [introducing navigator.identity](https://github.com/WICG/digital-identities/blob/main/proposals/navigator-identity-proposal.md)
112 | 
113 | # Open Questions
114 | 
115 | There are still many open questions, but a few big ones:
116 | 
117 | - To what extent does the browser introspect the request to wallets (for privacy and security reasons)? How much of that needs to interoperate between browsers, vs. be browser-specific points of differentiation in offering privacy features to users?
118 | - Will existing protocols ([example](https://github.com/openid/OpenID4VP/issues/125)) adopt this API?
119 | - Will regulation ([example](https://digital-strategy.ec.europa.eu/en/library/european-digital-identity-architecture-and-reference-framework-outline)) adopt this API?
120 | 
121 | # Out of Scope
122 | 
123 | The following topics are currently out of scope for the API:
124 | 
125 | - A website (issuer) requesting the issuance of a digital credential to a digital wallet
126 | - A website (verifier) explicitly requesting multiple digital credentials from multiple wallets in the same request
127 | 
128 | # Related Work
129 | 
130 | - [Real-world identity on the web - risks and mitigations](https://github.com/w3cping/credential-considerations/blob/main/risks.md#the-consequences-of-a-failure-to-act-are-as-valid-as-those-of-acting), Rick Byers
131 | - [Concerns with custom schemes for identity presentment](https://github.com/WICG/digital-identities/blob/main/custom-schemes.md), Rick Byers
132 | - [Digital Credentials API Standards Position](https://github.com/WebKit/standards-positions/issues/332#issuecomment-2019400609), Marcos Caceres
133 | - [User considerations for credential presentation on the Web](https://github.com/w3cping/credential-considerations/blob/main/credentials-considerations.md), Nick Doty
134 | - [Privacy Principles](https://w3ctag.github.io/privacy-principles/#identity), Jeffrey Yasskin and Robin Berjon
135 | - [Intent to deprecate forwarding of mdoc-scheme URLs as Android Intents](https://groups.google.com/a/chromium.org/g/blink-dev/c/wcCrcMTELS0/m/ZSPxAT0LAgAJ), Adam Langley
136 | - [Wallets on the web - PING @TPAC](https://docs.google.com/presentation/d/1Z7blMTME1tAQAdO-Wr42oVNN3CRIbklASjbJdB1JYOc/edit?resourcekey=0-ockU2NbemVbLEeF94-peNA#slide=id.p), Rick Byers
137 | - [Chromium: RWI privacy risk mitigation design](https://docs.google.com/document/d/1L68tmNXCQXucsCV8eS8CBd_F9FZ6TNwKNOaFkA8RfwI/edit#heading=h.8gq5f7p3it8q), Rick Byers
138 | 


--------------------------------------------------------------------------------
/horizontal-reviews/security-privacy.md:
--------------------------------------------------------------------------------
  1 | # [Self-Review Questionnaire: Security and Privacy](https://w3ctag.github.io/security-questionnaire/)
  2 | 
  3 | > 01.  What information does this feature expose,
  4 | >      and for what purposes?
  5 | 
  6 | High-value privacy sensitive claims from digital credentials, such as digital driver's licenses for both unique identification (such as for access to government services) and selective disclosure (such as for age verification). It does this through a one-time user-mediated communication channel from websites, to digital wallet applications, and back to websites. It is designed to be a better option than established lower-level communication channels like custom schemes, QR codes, and server-to-server network communication. How exactly this channel is used is up to the wallet applications and host operating system.
  7 | 
  8 | > 02.  Do features in your specification expose the minimum amount of information
  9 | >      necessary to implement the intended functionality?
 10 | 
 11 | A primary use case of the digital credentials API is to enable users to selectively disclose only the minimum required information, such as a cryptographic attestation that the user holds a California driver’s license for an adult. The use of selective disclosure, however, is a decision for the verifier website based on the use case. There are legitimate scenarios, such as creating or recovering an account on a government website, where uniquely identifiable and potentially non-resettable personally identifiable information (PII) might be exposed.
 12 | 
 13 | The API is designed to expect the use of response encryption so that this PII is exposed only to the requesting server and not any code running in the web page or browser. It is an [open question](https://github.com/WICG/digital-identities/issues/109) whether this response encryption is something we can reasonably enforce at this layer or not.
 14 | 
 15 | The API is also designed to require request transparency to enable user agents and operating systems to appropriately inform users about the level of privacy risk involved in the request. A major area of outstanding work is to outline in the specification our privacy and security guidance to implementers, but we already know that the [Chromium implementation](https://docs.google.com/document/d/1L68tmNXCQXucsCV8eS8CBd_F9FZ6TNwKNOaFkA8RfwI/edit) intends to show users stronger warnings in riskier scenarios such as those that lack the use of selective disclosure.
 16 | 
 17 | > 03.  Do the features in your specification expose personal information,
 18 | >      personally-identifiable information (PII), or information derived from
 19 | >      either?
 20 | 
 21 | Yes. The API is designed to help facilitate communication of personally-identifiable information (PII) from wallet applications to verifier web servers, through a relying party (a web application).
 22 | 
 23 | > 04.  How do the features in your specification deal with sensitive information?
 24 | 
 25 | The specification seeks to empower users, issuers, wallets and verifiers to present sensitive information in a more secure and private fashion than existing ad-hoc solutions.
 26 | 
 27 | Today, online identity verification (e.g., for know your customer (KYC)) is usually done by submitting photos of government identity documents. This is commonly done by users uploading photos containing the personally identifiable information (PII) using the web’s `<input type=file>` or similar mechanisms. Due to the privacy, security, and usability limits of this approach, credential issuers and verifiers are working to move to the use of wallet applications that can selectively disclose cryptographically-attested properties. Today, those approaches rely on generic browser-to-native-application communication paths, such as custom URL schemes and/or server-to-server communication.
 28 | 
 29 | The use of wallets aims to improve on the status quo of uploading images in a number of ways:
 30 |  * Enable selective disclosure (e.g., for more privacy-friendly age≥18 verification)
 31 |  * Enable the wallet to demonstrate legitimate possession of a credential by proving possession of key material bound to that credential
 32 |  * Enable end-to-end personally identifiable information (PII) encryption between the wallet application and the relevant verification server
 33 |  * Enable request authentication, where a wallet is required to cryptographically verify that the requester has permission to access the credential
 34 | 
 35 | Further, this specification aims to be an improvement over the existing communication channels websites use to talk to wallet apps by:
 36 |  * Enabling browsers and operating systems to provide meaningful credential selection and permission screens to users, prior to wallet applications becoming aware of the presentation request
 37 |  * Securely communicating the origin of the requesting site to the wallet application, so that it can implement its own MITM (man-in-the-middle) protection with support of WebPKI (Web Public Key Infrastructure)
 38 |  * Enabling browsers to inspect requests and provide additional UI affordances to users
 39 | 
 40 | > 05.  Do the features in your specification introduce state
 41 | >      that persists across browsing sessions?
 42 | 
 43 | No. In particular, the current scope is just about credential presentation (read-only). We have had requests to expand scope to consider credential issuance APIs but no work has begun on that.
 44 | 
 45 | > 06.  Do the features in your specification expose information about the
 46 | >      underlying platform to origins?
 47 | 
 48 | Not directly. Wallets may (intentionally or inadvertently) expose some information through this API (such as some indication of which wallet app the user is using). But the primary motivation for these wallets over traditional federated authentication systems is that the wallet can act in the user’s interest to protect their privacy even from the credential issuer. Users will often have their choice of multiple wallets and are expected to use reputation for privacy as part of their decision making. Issuers may  choose which wallets to support their credentials in and can impose privacy requirements on those wallets. That said, there is absolutely a risk that users could be surprised or even deceived by some wallets exposing information they didn't expect. We are [exploring](https://github.com/WICG/digital-credentials/issues/117) ways in which our specification could potentially help reduce this risk.
 49 | 
 50 | > 07.  Does this specification allow an origin to send data to the underlying
 51 | >      platform?
 52 | 
 53 | Yes. The credential presentation request is sent to the underlying platform to mediate.
 54 | 
 55 | > 08.  Do features in this specification enable access to device sensors?
 56 | 
 57 | Not directly. See question 10.
 58 | 
 59 | > 09.  Do features in this specification enable new script execution/loading
 60 | >      mechanisms?
 61 | 
 62 | No.
 63 | 
 64 | > 10.  Do features in this specification allow an origin to access other devices?
 65 | 
 66 | Not yet, but we expect to expand the API to enable cross-device presentation flows using the same mechanism used by passkeys ([FIDO CTAP](https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-client-to-authenticator-protocol-v2.2-rd-20230321.html)).
 67 | 
 68 | > 11.  Do features in this specification allow an origin some measure of control over
 69 | >      a user agent's native UI?
 70 | 
 71 | Not control, no. User agents may add additional affordances for user transparency and control.
 72 | 
 73 | > 12.  What temporary identifiers do the features in this specification create or
 74 | >      expose to the web?
 75 | 
 76 | None directly. Wallets may expose temporary identifiers, such as in the MSOs used for selective disclosure of ISO 18013-5 mdocs.
 77 | 
 78 | > 13.  How does this specification distinguish between behavior in first-party and
 79 | >      third-party contexts?
 80 | 
 81 | The API is currently available only in first-party contexts, but there is an [open issue](https://github.com/WICG/digital-identities/issues/78) to explore adding a permission policy to enable requests in third-party contexts.
 82 | 
 83 | > 14.  How do the features in this specification work in the context of a browser’s
 84 | >      Private Browsing or Incognito mode?
 85 | 
 86 | Like other browser authentication (e.g., WebAuthn) and identification (e.g., autofill) features, the feature is available to users to use in private browsing. Regardless of whether private browsing is in use, the feature is designed to not communicate information without the user’s explicit permission each and every time it's invoked. There are legitimate use cases for this API in private browsing such as privacy-preserving age verification.
 87 | 
 88 | > 15.  Does this specification have both "Security Considerations" and "Privacy
 89 | >      Considerations" sections?
 90 | 
 91 | Not yet, but it will. The specification is still being written as we incubate the API and gain experience with real-world experiments.
 92 | 
 93 | > 16.  Do features in your specification enable origins to downgrade default
 94 | >      security protections?
 95 | 
 96 | No
 97 | 
 98 | > 17.  What happens when a document that uses your feature is kept alive in BFCache
 99 | >      (instead of getting destroyed) after navigation, and potentially gets reused
100 | >      on future navigations back to the document?
101 | 
102 | Implementations should fail or postpone any requests which occur while the page is not visible to the user. The spec may introduce a [requirement for user activation](https://github.com/WICG/digital-identities/issues/91) which could help with this.
103 | 
104 | > 18.  What happens when a document that uses your feature gets disconnected?
105 | 
106 | Probably just silently ignored, but [we'll discuss](https://github.com/WICG/digital-identities/issues/112).
107 | 
108 | > 19.  What should this questionnaire have asked?
109 | 
110 | What are the security and privacy implications of not shipping this feature? How does this feature fit into the larger privacy risk landscape. We believe the feature will lead to a reduced risk relative to the status quo, but this is very subjective and hard to demonstrate definitively.
111 | 
112 | 


--------------------------------------------------------------------------------
/index.html:
--------------------------------------------------------------------------------
   1 | <!DOCTYPE html>
   2 | <html lang="en">
   3 |   <head>
   4 |     <meta charset="utf-8">
   5 |     <title>
   6 |       Digital Credentials
   7 |     </title>
   8 |     <script src="https://www.w3.org/Tools/respec/respec-w3c" class=
   9 |     "remove"></script>
  10 |     <script class="remove">
  11 |     "use strict";
  12 |     // See https://github.com/w3c/respec/wiki/ for how to configure ReSpec
  13 |     var respecConfig = {
  14 |       github: "w3c-fedid/digital-credentials",
  15 |       editors: [
  16 |         {
  17 |           name: "Marcos Caceres",
  18 |           email: "marcosc@apple.com",
  19 |           company: "Apple Inc.",
  20 |           companyURL: "https://apple.com",
  21 |         },
  22 |         {
  23 |           name: "Tim Cappalli",
  24 |           email: "tim.cappalli@okta.com",
  25 |           company: "Okta",
  26 |           companyURL: "https://okta.com",
  27 |         },
  28 |         {
  29 |           name: "Mohamed Amir Yosef",
  30 |           email: "mamir@google.com",
  31 |           company: "Google Inc.",
  32 |           companyURL: "https://google.com",
  33 |         },
  34 |         {
  35 |           name: "Sam Goto",
  36 |           email: "goto@google.com",
  37 |           company: "Google Inc.",
  38 |           companyURL: "https://google.com",
  39 |           retiredDate: "2025-05-02",
  40 |         },
  41 |         // Add additional editors here.
  42 |         // https://github.com/w3c/respec/wiki/editors
  43 |       ],
  44 |       latestVersion: null,
  45 |       shortName: "digital-credentials",
  46 |       specStatus: "ED",
  47 |       edDraftURI: "https://w3c-fedid.github.io/digital-credentials/",
  48 |       group: "fedid",
  49 |       github: "https://github.com/w3c-fedid/digital-credentials",
  50 |       localBiblio: {
  51 |         "credential-considerations": {
  52 |           title: "User considerations for credentials on the Web",
  53 |           href: "https://github.com/w3c/credential-considerations/blob/main/credentials-considerations.md",
  54 |           authors: ["Nick Doty", "Rick Byers"],
  55 |           date: "2025-03-26",
  56 |           publisher: "W3C"
  57 |         },
  58 |         "threat-model-decentralized-identities": {
  59 |           title: "Threat Model for Decentralized Identities",
  60 |           href: "https://github.com/w3c-cg/threat-modeling/blob/main/models/decentralized-identities.md",
  61 |           authors: ["Simone Onofri"],
  62 |           date: "2025-05-28",
  63 |           publisher: "W3C"
  64 |         },
  65 |       },
  66 |       xref: {
  67 |         profile: "web-platform",
  68 |       },
  69 |     };
  70 |     </script>
  71 |   </head>
  72 |   <body data-cite="credential-management-1 vc-data-model">
  73 |     <section id="abstract">
  74 |       <p>
  75 |         This document specifies an API to enable [=user agents=] to mediate
  76 |         presentation and issuance of digital credentials such as a driver's
  77 |         license, government-issued identification card, and/or [=credential
  78 |         type examples|other types of digital credential=]. The API builds on
  79 |         [[[credential-management-1]]] as a means by which to request or issue a
  80 |         digital credential from a user agent or underlying platform.
  81 |       </p>
  82 |     </section>
  83 |     <section id="sotd">
  84 |       <p>
  85 |         This is an unofficial proposal.
  86 |       </p>
  87 |     </section>
  88 |     <h2>
  89 |       Introduction
  90 |     </h2>
  91 |     <p>
  92 |       This document defines an API enabling a website to request presentation
  93 |       and issuance of a [=digital credential=].
  94 |     </p>
  95 |     <p>
  96 |       The API design is agnostic to both credential [=digital
  97 |       credential/presentation requests|presentation=] [=digital
  98 |       credential/exchange protocols=], credential [=digital credential/issuance
  99 |       request|issuance=] [=digital credential/issuance protocols|protocols=]
 100 |       and credential formats. However, to promote interoperability this
 101 |       document includes a [[[#protocol-registry]]].
 102 |     </p>
 103 |     <p>
 104 |       The API is designed to support the following goals:
 105 |     </p>
 106 |     <ul>
 107 |       <li>Keep the acts of [=digital credential/presentation
 108 |       requests|requesting=] and [=digital credential/issuance
 109 |       requests|issuing=] separate from the specific [=digital
 110 |       credential/exchange protocol=] and [=digital credential/issuance
 111 |       protocol=] respectively; thereby enabling the extensibility of such
 112 |       protocols and credential formats.
 113 |       </li>
 114 |       <li>Require [=digital credential/presentation requests=] and [=digital
 115 |       credential/issuance requests=] to be unencrypted, enabling user-agent
 116 |       inspection for risk analysis.
 117 |       </li>
 118 |       <li>Assume opaque (i.e., encrypted) [=digital credential/presentation
 119 |       responses=] and [=digital credential/issuance responses=], enabling
 120 |       issuers, verifiers, and holders to control where potentially sensitive
 121 |       personally identifiable information is exposed.
 122 |       </li>
 123 |       <li>Require [=transient activation=] to perform [=digital
 124 |       credential/presentation requests=] or [=digital credential/issuance
 125 |       requests=], ensuring that sites cannot silently query for nor issue
 126 |       digital credentials, nor communicate with wallet providers, without the
 127 |       user's active participation and confirmation of each action.
 128 |       </li>
 129 |       <li>Enable platform-provided credential selection UX when multiple wallet
 130 |       applications have credentials that match a [=digital
 131 |       credential/presentation request=].
 132 |       </li>
 133 |       <li>Enable platform-provided wallet selection UX when multiple wallet
 134 |       applications support an [=digital credential/issuance request=].
 135 |       </li>
 136 |       <li>Enable platforms to provide secure cross-device [=digital
 137 |       credential/presentation requests=] and [=digital credential/issuance
 138 |       requests=] with proximity checks.
 139 |       </li>
 140 |     </ul>
 141 |     <p id="credential-type-examples">
 142 |       [=Digital credentials=] of many types can be presented and issued using
 143 |       this API. <dfn data-lt="credential type examples">Examples of these
 144 |       types</dfn> include:
 145 |     </p>
 146 |     <ul>
 147 |       <li>a driving license, passport, or other identity card issued by a
 148 |       government institution
 149 |       </li>
 150 |       <li>a travel authorization document issued by an embassy or consulate
 151 |       </li>
 152 |       <li>a proof of employment issued by a public or private organization
 153 |       </li>
 154 |       <li>a proof of education or professional training issued by an
 155 |       institution
 156 |       </li>
 157 |       <li>and many other scenarios as described in <a href=
 158 |       "https://www.w3.org/TR/vc-use-cases/">Verifiable Credentials Use
 159 |       Cases</a>
 160 |       </li>
 161 |     </ul>
 162 |     <h2>
 163 |       Model
 164 |     </h2>
 165 |     <p class="note" title="Definitions under discussion">
 166 |       The goal of the definitions in this section is to reuse or establish
 167 |       terminology that is common across a variety of digital credential formats
 168 |       and protocols. Discussions surrounding these definitions are active and
 169 |       the definitions are likely to change over the next several months.
 170 |     </p>
 171 |     <dl class="definitions" data-sort="" data-cite="vc-data-model-2.0">
 172 |       <dt>
 173 |         <dfn>Digital credential</dfn>
 174 |       </dt>
 175 |       <dd>
 176 |         A cryptographically signed digital document containing one or more
 177 |         [=claims=] made by an [=issuer=] about one or more [=subjects=].
 178 |         <p class="note" title="Focus on digital credentials about people">
 179 |           This specification is currently focused on digital credentials
 180 |           pertaining to people.
 181 |         </p>
 182 |       </dd>
 183 |       <dt>
 184 |         <dfn data-dfn-for="digital credential" data-local-lt=
 185 |         "presentation">Presentation request</dfn>
 186 |       </dt>
 187 |       <dd>
 188 |         A presentation request is a request for a [=digital credential=]
 189 |         composed of [=digital credential/request data=] and a [=digital
 190 |         credential/exchange protocol=].
 191 |       </dd>
 192 |       <dt>
 193 |         <dfn data-dfn-for="digital credential">request data</dfn>
 194 |       </dt>
 195 |       <dd>
 196 |         A format that [=verifier=] software or a [=user agent=] uses, via an
 197 |         [=digital credential/exchange protocol=], to request a [=digital
 198 |         credential=] from a [=holder=].
 199 |       </dd>
 200 |       <dt>
 201 |         <dfn data-dfn-for="digital credential" data-local-lt=
 202 |         "presentation response">Presentation response</dfn>
 203 |       </dt>
 204 |       <dd>
 205 |         A format that a [=holder's=] software, such as a digital wallet, uses,
 206 |         via an [=digital credential/exchange protocol=], to respond to a
 207 |         [=digital credential/presentation request=] by a [=verifier=].
 208 |       </dd>
 209 |       <dt>
 210 |         <dfn data-dfn-for="digital credential" data-local-lt=
 211 |         "issuance">Issuance request</dfn>
 212 |       </dt>
 213 |       <dd>
 214 |         An issuance request is a request to issue a [=digital credential=]
 215 |         composed of some [=digital credential/issuance request data=] and an
 216 |         [=digital credential/issuance protocol=].
 217 |       </dd>
 218 |       <dt>
 219 |         <dfn data-dfn-for="digital credential">issuance request data</dfn>
 220 |       </dt>
 221 |       <dd>
 222 |         A data structure that an [=issuer=] or a [=user agent=], via an
 223 |         [=digital credential/issuance protocol=], to request the issuance of a
 224 |         [=digital credential=] by an [=issuer=].
 225 |       </dd>
 226 |       <dt>
 227 |         <dfn data-dfn-for="digital credential">Issuance response</dfn>
 228 |       </dt>
 229 |       <dd>
 230 |         A format that [=holder=] uses, via an [=digital credential/issuance
 231 |         protocol=], to respond to an [=digital credential/issuance request=] by
 232 |         an [=issuer=].
 233 |       </dd>
 234 |       <dt>
 235 |         <dfn data-dfn-for="digital credential" data-local-lt=
 236 |         "exchange protocol">Exchange protocol</dfn>
 237 |       </dt>
 238 |       <dd>
 239 |         A protocol used for exchanging a [=digital credential=] between a
 240 |         [=holder=] and a [=verifier=]. See section [[[#protocol-registry]]].
 241 |       </dd>
 242 |       <dt>
 243 |         <dfn data-dfn-for="digital credential" data-local-lt=
 244 |         "issuance protocol">Issuance protocol</dfn>
 245 |       </dt>
 246 |       <dd>
 247 |         A protocol used for communication between an [=issuer=] and a
 248 |         [=holder=] during the issuance of a [=digital credential=]. See section
 249 |         [[[#protocol-registry]]].
 250 |       </dd>
 251 |     </dl>
 252 |     <h2>
 253 |       Scope
 254 |     </h2>
 255 |     <p>
 256 |       The following items are within the scope of this specification:
 257 |     </p>
 258 |     <ul>
 259 |       <li>Requesting a [=digital credential=], including mechanisms for secure
 260 |       presentation.
 261 |       </li>
 262 |       <li>Requesting issuance of a [=digital credential=].
 263 |       </li>
 264 |       <li>Ensuring that when an API call is made, the website does not learn
 265 |       anything about the a holder's [=digital credentials=] or their software
 266 |       unless the [=user agent=] has previously received user consent.
 267 |       </li>
 268 |       <li>Ensuring that any installed application software will not learn
 269 |       anything about a given [=request=] unless the [=holder=] explicitly
 270 |       consents to use that software.
 271 |       </li>
 272 |     </ul>
 273 |     <p>
 274 |       The following items are out of scope:
 275 |     </p>
 276 |     <ul>
 277 |       <li>UI/UX considerations, with the exception of privacy considerations,
 278 |       which are addressed to ensure the protection of user data during the
 279 |       request process.
 280 |       </li>
 281 |     </ul>
 282 |     <h2>
 283 |       Extensions to `CredentialRequestOptions` dictionary
 284 |     </h2>
 285 |     <pre class="idl">
 286 |     partial dictionary CredentialRequestOptions {
 287 |       DigitalCredentialRequestOptions digital;
 288 |     };
 289 |     </pre>
 290 |     <h3>
 291 |       The `digital` member
 292 |     </h3>
 293 |     <p>
 294 |       The <dfn data-dfn-for="CredentialRequestOptions">digital</dfn> member
 295 |       allows for options to configure the request for a [=digital credential=].
 296 |     </p>
 297 |     <h2>
 298 |       The `DigitalCredentialRequestOptions` dictionary
 299 |     </h2>
 300 |     <pre class="idl">
 301 |     dictionary DigitalCredentialRequestOptions {
 302 |       sequence&lt;DigitalCredentialGetRequest&gt; requests;
 303 |     };
 304 |     </pre>
 305 |     <h3>
 306 |       The `requests` member
 307 |     </h3>
 308 |     <p>
 309 |       The <dfn data-dfn-for="DigitalCredentialRequestOptions">requests</dfn>
 310 |       specify an [=digital credential/exchange protocol=] and [=digital
 311 |       credential/request data=], which the user agent MAY match against a
 312 |       holder's software, such as a digital wallet.
 313 |     </p>
 314 |     <h2>
 315 |       The `DigitalCredentialGetRequest` dictionary
 316 |     </h2>
 317 |     <p>
 318 |       The {{DigitalCredentialGetRequest}} dictionary represents a [=digital
 319 |       credential/presentation request=]. It is used to specify an [=digital
 320 |       credential/exchange protocol=] and some [=digital credential/request
 321 |       data=], which the user agent MAY match against software used by a holder,
 322 |       such as a digital wallet.
 323 |     </p>
 324 |     <pre class="idl">
 325 |       dictionary DigitalCredentialGetRequest {
 326 |         required DOMString protocol;
 327 |         required object data;
 328 |       };
 329 |       </pre>
 330 |     <h3>
 331 |       The `protocol` member
 332 |     </h3>
 333 |     <p>
 334 |       The <dfn data-dfn-for="DigitalCredentialGetRequest">protocol</dfn> member
 335 |       denotes the [=digital credential/exchange protocol=].
 336 |     </p>
 337 |     <p>
 338 |       The {{DigitalCredentialCreateRequest/protocol}} member's value can be one
 339 |       of the well-defined protocol identifiers defined in
 340 |       [[[#protocol-registry]]] or a custom protocol identifier.
 341 |     </p>
 342 |     <h3>
 343 |       The `data` member
 344 |     </h3>
 345 |     <p>
 346 |       The <dfn data-dfn-for="DigitalCredentialGetRequest">data</dfn> member is
 347 |       the [=digital credential/request data=] to be handled by the holder's
 348 |       credential provider, such as a digital identity wallet.
 349 |     </p>
 350 |     <h2>
 351 |       Extensions to `CredentialCreationOptions` dictionary
 352 |     </h2>
 353 |     <pre class="idl">
 354 |     partial dictionary CredentialCreationOptions {
 355 |       DigitalCredentialCreationOptions digital;
 356 |     };
 357 |     </pre>
 358 |     <h3>
 359 |       The `digital` member
 360 |     </h3>
 361 |     <p>
 362 |       The <dfn data-dfn-for="CredentialCreationOptions">digital</dfn> member
 363 |       allows for options to configure the issuance of a [=digital credential=].
 364 |     </p>
 365 |     <h2>
 366 |       The `DigitalCredentialCreationOptions` dictionary
 367 |     </h2>
 368 |     <pre class="idl">
 369 |     dictionary DigitalCredentialCreationOptions {
 370 |       sequence&lt;DigitalCredentialCreateRequest&gt; requests;
 371 |     };
 372 |     </pre>
 373 |     <h3>
 374 |       The `requests` member
 375 |     </h3>
 376 |     <p>
 377 |       The <dfn data-dfn-for="DigitalCredentialCreationOptions">requests</dfn>
 378 |       specify an [=digital credential/issuance protocol=] and [=digital
 379 |       credential/request data=], which the user agent MAY forward to a
 380 |       [=holder=].
 381 |     </p>
 382 |     <h2>
 383 |       The `DigitalCredentialCreateRequest` dictionary
 384 |     </h2>
 385 |     <p>
 386 |       The {{DigitalCredentialCreateRequest}} dictionary represents an [=digital
 387 |       credential/issuance request=]. It is used to specify an [=digital
 388 |       credential/issuance protocol=] and some [=digital credential/request
 389 |       data=], to communicate the issuance request between the issuer and the
 390 |       holder.
 391 |     </p>
 392 |     <pre class="idl">
 393 |     dictionary DigitalCredentialCreateRequest {
 394 |       required DOMString protocol;
 395 |       required object data;
 396 |     };
 397 |     </pre>
 398 |     <h3>
 399 |       The `protocol` member
 400 |     </h3>
 401 |     <p>
 402 |       The <dfn data-dfn-for="DigitalCredentialCreateRequest">protocol</dfn>
 403 |       member denotes the [=digital credential/issuance protocol=].
 404 |     </p>
 405 |     <p>
 406 |       The {{DigitalCredentialCreateRequest/protocol}} member's value is be one
 407 |       of the well-defined keys defined in [[[#protocol-registry]]] or any other
 408 |       custom one.
 409 |     </p>
 410 |     <h3>
 411 |       The `data` member
 412 |     </h3>
 413 |     <p>
 414 |       The <dfn data-dfn-for="DigitalCredentialCreateRequest">data</dfn> member
 415 |       is the [=digital credential/request data=] to be handled by the holder's
 416 |       credential provider, such as a digital identity wallet.
 417 |     </p>
 418 |     <h2>
 419 |       The `DigitalCredential` interface
 420 |     </h2>
 421 |     <p>
 422 |       The <dfn>DigitalCredential</dfn> interface represents a conceptual
 423 |       [=digital credential=].
 424 |     </p>
 425 |     <p>
 426 |       [=User mediation=] is always
 427 |       {{CredentialMediationRequirement/"required"}}. [=Request a
 428 |       credential|Requesting a DigitalCredential credential=] does not support
 429 |       {{CredentialMediationRequirement/"conditional"}},
 430 |       {{CredentialMediationRequirement/"optional"}}, or
 431 |       {{CredentialMediationRequirement/"silent"}} [=user mediation=]. If
 432 |       {{CredentialsContainer/get()}} is called with anything other than
 433 |       {{CredentialMediationRequirement/"required"}}, a {{TypeError}} will be
 434 |       thrown.
 435 |     </p>
 436 |     <pre class="idl">
 437 |     [Exposed=Window, SecureContext]
 438 |     interface DigitalCredential : Credential {
 439 |       readonly attribute DOMString protocol;
 440 |       [SameObject] readonly attribute object data;
 441 |     };
 442 |     </pre>
 443 |     <p>
 444 |       {{DigitalCredential}} instances are [=Credential/origin bound=].
 445 |     </p>
 446 |     <h3>
 447 |       The `protocol` member
 448 |     </h3>
 449 |     <p>
 450 |       The <dfn data-dfn-for="DigitalCredential">protocol</dfn> member is the
 451 |       [=digital credential/exchange protocol=] that was used to request the
 452 |       [=digital credential=], or the [=digital credential/issuance protocol=]
 453 |       that was used to issue the [=digital credential=].
 454 |     </p>
 455 |     <h3>
 456 |       The `data` member
 457 |     </h3>
 458 |     <p>
 459 |       The <dfn data-dfn-for="DigitalCredential">data</dfn> member is the
 460 |       credential's response data. It contains the subset of JSON-parseable
 461 |       object types.
 462 |     </p>
 463 |     <h2>
 464 |       Integration with Credential Management API
 465 |     </h2>
 466 |     <aside class="issue" data-number="65"></aside>
 467 |     <h3>
 468 |       [[\DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)
 469 |       internal method
 470 |     </h3>
 471 |     <p>
 472 |       When invoked, the <dfn class="export" data-dfn-for=
 473 |       "DigitalCredential">[[\DiscoverFromExternalSource]](origin, options,
 474 |       sameOriginWithAncestors)</dfn> internal method MUST:
 475 |     </p>
 476 |     <ol class="algorithm">
 477 |       <li>Let |global| be [=this=]'s [=relevant global object=].
 478 |       </li>
 479 |       <li>Let |document| be |global|'s [=associated `Document`=].
 480 |       </li>
 481 |       <li>If |document| is not a [=Document/fully active descendant of a
 482 |       top-level traversable with user attention=], [=exception/throw=]
 483 |       {{"NotAllowedError"}} {{DOMException}}.
 484 |       </li>
 485 |       <li>If |window| does not have [=transient activation=],
 486 |       [=exception/throw=] {{"NotAllowedError"}} {{DOMException}}.
 487 |       </li>
 488 |       <li>[=Consume user activation=] of |window|.
 489 |       </li>
 490 |       <li>Let |requests| be |options|'s {{CredentialRequestOptions/digital}}'s
 491 |       {{DigitalCredentialRequestOptions/requests}} member.
 492 |       </li>
 493 |       <li>If |requests| is empty, [=exception/throw=] a {{TypeError}}.
 494 |       </li>
 495 |       <li>
 496 |         <aside class="issue">
 497 |           Details of how to actually get the [=digital credential=] are
 498 |           forthcoming.
 499 |         </aside>
 500 |       </li>
 501 |       <li>Return a {{DigitalCredential}}.
 502 |       </li>
 503 |     </ol>
 504 |     <h3>
 505 |       [[\Store]](credential, sameOriginWithAncestors) internal method
 506 |     </h3>
 507 |     <p>
 508 |       When invoked, the <dfn class="export" data-dfn-for=
 509 |       "DigitalCredential">[[\Store]](credential, sameOriginWithAncestors)</dfn>
 510 |       MUST call the default implementation of {{Credential}}'s
 511 |       {{Credential/[[Store]](credential, sameOriginWithAncestors)}} internal
 512 |       method with the same arguments.
 513 |     </p>
 514 |     <h3>
 515 |       [[\Create]](origin, options, sameOriginWithAncestors) internal method
 516 |     </h3>
 517 |     <p>
 518 |       When invoked, the <dfn class="export" data-dfn-for=
 519 |       "DigitalCredential">[[\Create]](origin, options,
 520 |       sameOriginWithAncestors)</dfn> internal method, if the user agent doesn't
 521 |       support issuance, call the default implementation of {{Credential}}'s
 522 |       {{Credential/[[Create]](origin,options, sameOriginWithAncestors)}}
 523 |       internal method with the same arguments. Otherwise:
 524 |     </p>
 525 |     <ol class="algorithm">
 526 |       <li>Let |global| be [=this=]'s [=relevant global object=].
 527 |       </li>
 528 |       <li>Let |document| be |global|'s [=associated `Document`=].
 529 |       </li>
 530 |       <li>If |document| is not a [=Document/fully active descendant of a
 531 |       top-level traversable with user attention=], [=exception/throw=]
 532 |       {{"NotAllowedError"}} {{DOMException}}.
 533 |       </li>
 534 |       <li>If |window| does not have [=transient activation=],
 535 |       [=exception/throw=] {{"NotAllowedError"}} {{DOMException}}.
 536 |       </li>
 537 |       <li>[=Consume user activation=] of |window|.
 538 |       </li>
 539 |       <li>Let |requests| be |options|'s {{CredentialCreationOptions/digital}}'s
 540 |       {{DigitalCredentialCreationOptions/requests}} member.
 541 |       </li>
 542 |       <li>If |requests| is empty, [=exception/throw=] a {{TypeError}}.
 543 |       </li>
 544 |       <li>
 545 |         <aside class="issue">
 546 |           Details of how to actually issue the [=digital credential=] are
 547 |           forthcoming.
 548 |         </aside>
 549 |       </li>
 550 |       <li>Return a newly constructed {{DigitalCredential}} with
 551 |       {{DigitalCredential/protocol}} initialized to the protocol that was used
 552 |       to issue this credential, and {{DigitalCredential/data}} initialized to
 553 |       an [=digital credential/issuance response=] defined by that [=digital
 554 |       credential/issuance protocol=].
 555 |       </li>
 556 |     </ol>
 557 |     <h3>
 558 |       [[\type]] internal slot
 559 |     </h3>
 560 |     <p>
 561 |       The {{DigitalCredential}} [=interface object=] has an internal slot named
 562 |       <dfn class="export" data-dfn-for="DigitalCredential">[[\type]]</dfn>
 563 |       whose value is "digital".
 564 |     </p>
 565 |     <h3>
 566 |       [[\discovey]] internal slot
 567 |     </h3>
 568 |     <p>
 569 |       The {{DigitalCredential}} [=interface object=] has an internal slot named
 570 |       <dfn class="export" data-dfn-for="DigitalCredential">[[\discovery]]</dfn>
 571 |       whose value is "remote".
 572 |     </p>
 573 |     <section class="informative">
 574 |       <h3>
 575 |         User permission
 576 |       </h3>
 577 |       <p data-cite="permissions">
 578 |         The <cite>Digital Credential API</cite> is a [=powerful feature=] that
 579 |         requires [=express permission=] from an end-user. This requirement is
 580 |         normatively enforced when calling {{CredentialsContainer}}'s
 581 |         {{CredentialsContainer/get()}} method.
 582 |       </p>
 583 |     </section>
 584 |     <section id="permissions-policy" data-cite="permissions-policy">
 585 |       <h2>
 586 |         Permissions Policy integration
 587 |       </h2>
 588 |       <p>
 589 |         This specification defines a [=policy-controlled feature=] identified
 590 |         by the string <dfn class="permission">"digital-credentials-get"</dfn>.
 591 |         Its [=policy-controlled feature/default allowlist=] is [=default
 592 |         allowlist/'self'=].
 593 |       </p>
 594 |     </section>
 595 |     <h2 id="protocol-registry">
 596 |       Registry of protocols
 597 |     </h2>
 598 |     <p>
 599 |       Initiating the registration a protocol is done by <a href=
 600 |       "https://github.com/w3c-fedid/digital-credentials/issues">filing an
 601 |       issue</a> in our GitHub repository.
 602 |     </p>
 603 |     <p>
 604 |       The following is the registry of [=digital credential/exchange
 605 |       protocols=] and [=digital credential/issuance protocols=] that are
 606 |       supported by this specification.
 607 |     </p>
 608 |     <p class="note" title="Official Registry" data-cite="w3c-process">
 609 |       It is expected that this registry will be become a [=W3C registry=] in
 610 |       the future.
 611 |     </p>
 612 |     <h3>
 613 |       General inclusion criteria
 614 |     </h3>
 615 |     <aside class="note">
 616 |       The below criteria are a work in progress and are likely to change as
 617 |       this document evolves.
 618 |     </aside>
 619 |     <p>
 620 |       To be included in the registry, the [=digital credential/exchange
 621 |       protocol=]:
 622 |     </p>
 623 |     <ol>
 624 |       <li>MUST be standardized at a <a href=
 625 |       "https://www.w3.org/liaisons/">consortium the W3C liaises with</a>
 626 |       </li>
 627 |       <li>MUST be defined in a specification which is freely and publicly
 628 |       available at the stable URL listed in the registry.
 629 |       </li>
 630 |       <li>MUST define a representation, as either a [[WebIDL]] [=dictionary=]
 631 |       or a JSON object, of the [=digital credential/exchange protocol=] request
 632 |       structure (i.e., the [=dictionary=] which defines the semantics and
 633 |       validation of the {{DigitalCredentialGetRequest}}'s
 634 |       {{DigitalCredentialGetRequest/data}} member) and the [=digital
 635 |       credential/issuance protocol=] request structure (i.e., the
 636 |       [=dictionary=] which defines the semantics and validation of the
 637 |       {{DigitalCredentialCreateRequest}}'s
 638 |       {{DigitalCredentialCreateRequest/data}} member).
 639 |       </li>
 640 |       <li>MUST define a representation, as either a [[WebIDL]] [=dictionary=]
 641 |       or a JSON object, of the [=digital credential/exchange protocol=]
 642 |       response structure (i.e., the [=dictionary=] which defines the semantics
 643 |       and validation of the {{DigitalCredential}}'s {{DigitalCredential/data}}
 644 |       member.
 645 |       </li>
 646 |       <li>MUST define validation rules for members of the request and response
 647 |       structures.
 648 |       </li>
 649 |       <li>MUST have undergone privacy review by the W3C's <a href=
 650 |       "https://www.w3.org/Privacy/IG/">Privacy Interest Group</a> and
 651 |         <a href="https://www.w3.org/groups/wg/fedid/">Federated Identity
 652 |         Working Group</a>.
 653 |         <aside class="note" title="Organizing reviews">
 654 |           Once an expression of registration is received via GitHub, the
 655 |           registry maintainers will organize the privacy review with the
 656 |           <a href="https://www.w3.org/Privacy/IG/">Privacy Interest Group</a> .
 657 |           Please see the [[[[security-privacy-questionnaire]]] for the kind of
 658 |           questions that will be asked of the protocol you are registering.
 659 |         </aside>
 660 |       </li>
 661 |       <li>MUST have undergone security review by the <a href=
 662 |       "https://www.w3.org/groups/ig/security/">Security Interest Group</a>.
 663 |       </li>
 664 |       <li>MUST have implementation commitment from at least one browser engine,
 665 |       one credential provider/wallet, and one issuer or verifier (depending on
 666 |       the protocol type). Each component MUST be from independent
 667 |       organizations.
 668 |       </li>
 669 |       <li>MUST have formally recorded consensus by the Federated Identity
 670 |       Working Group to be included in the registry.
 671 |       </li>
 672 |     </ol>
 673 |     <h4>
 674 |       Presentation-specific inclusion criteria
 675 |     </h4>
 676 |     <p>
 677 |       To be included as a presentation protocol in the registry (used with
 678 |       `navigator.credentials.get`), the [=digital credential/exchange
 679 |       protocol=]:
 680 |     </p>
 681 |     <ol>
 682 |       <li>MUST support response encryption.
 683 |       </li>
 684 |       <li>MUST encrypt any response containing personally identifiable
 685 |       information (PII).
 686 |       </li>
 687 |     </ol>
 688 |     <h3>
 689 |       Change process
 690 |     </h3>
 691 |     <p>
 692 |       To add a new [=digital credential/exchange protocol=] to the registry, or
 693 |       to update an existing one:
 694 |     </p>
 695 |     <dl>
 696 |       <dt>
 697 |         Define a <dfn data-dfn-for="registry" data-local-lt=
 698 |         "identifier">protocol identifier</dfn>.
 699 |       </dt>
 700 |       <dd>
 701 |         The protocol identifier MUST be a unique string that is not already in
 702 |         use in the registry. Use only lowercase ASCII letters, digits, and
 703 |         hyphens (e.g., "protocol", "the-protocol"). The protocol identifier
 704 |         MUST uniquely define the set of required parameters and/or behavior
 705 |         that a digital credential provider implementation needs to support to
 706 |         successfully handle the request. If the set of required parameters or
 707 |         behaviors is updated in a way which would require a digital credential
 708 |         provider to also require an update to remain functional, a new protocol
 709 |         identifier MUST be assigned and be added to the registry.
 710 |       </dd>
 711 |       <dt>
 712 |         Specify a <dfn data-dfn-for="registry" data-local-lt="type">protocol
 713 |         type</dfn>.
 714 |       </dt>
 715 |       <dd>
 716 |         The protocol type is either "Presentation" for presentation protocols
 717 |         used with `navigator.credentials.get` or "Issuance" for issuance
 718 |         protocols used with `navigator.credentials.create`.
 719 |       </dd>
 720 |       <dt>
 721 |         <dfn data-dfn-for="registry" data-local-lt="description">Describe the
 722 |         protocol</dfn>.
 723 |       </dt>
 724 |       <dd>
 725 |         The description MUST be a brief summary of the protocol's purpose and
 726 |         use case.
 727 |       </dd>
 728 |       <dt>
 729 |         Provide a <dfn data-dfn-for="registry" data-local-lt="link">link to the
 730 |         specification</dfn>.
 731 |       </dt>
 732 |       <dd>
 733 |         The specification MUST be a stable URL that points to the authoritative
 734 |         source for the protocol, including validation rules.
 735 |       </dd>
 736 |     </dl>
 737 |     <p>
 738 |       [=User agents=] MUST support the following [=digital credential/exchange
 739 |       protocols=]:
 740 |     </p>
 741 |     <table class="data">
 742 |       <caption>
 743 |         Table of officially registered [=digital credential/exchange
 744 |         protocols=].
 745 |       </caption>
 746 |       <thead>
 747 |         <tr>
 748 |           <th>
 749 |             [=registry/identifier|Protocol identifier=]
 750 |           </th>
 751 |           <th>
 752 |             [=registry/Type=]
 753 |           </th>
 754 |           <th>
 755 |             [=registry/Description=]
 756 |           </th>
 757 |           <th>
 758 |             [=registry/link|Specification=]
 759 |           </th>
 760 |         </tr>
 761 |       </thead>
 762 |       <tbody>
 763 |         <tr>
 764 |           <td colspan="3">
 765 |             Coming soon...
 766 |           </td>
 767 |         </tr>
 768 |       </tbody>
 769 |     </table>
 770 |     <section class="informative">
 771 |       <h2>
 772 |         Security Considerations
 773 |       </h2>
 774 |       <div class="issue" title=
 775 |       "Security Considerations section is a work in progress">
 776 |         <p>
 777 |           This section is a work in progress as this document evolves.
 778 |         </p>
 779 |         <p>
 780 |           The documents listed below outline initial security considerations
 781 |           for Digital Credentials, both broadly and for presentation on the
 782 |           web. Their contents will be integrated into this document gradually.
 783 |         </p>
 784 |         <ul>
 785 |           <li>
 786 |             <a href=
 787 |             "https://github.com/WICG/digital-credentials/blob/main/horizontal-reviews/security-privacy.md">
 788 |             TAG Security and Privacy Considerations Questionnaire (WIP)</a>
 789 |           </li>
 790 |           <li>
 791 |             <a href=
 792 |             "https://github.com/w3c-cg/threat-modeling/blob/main/models/decentralized-identities.md">
 793 |             Threat Model for Decentralized Identities</a>
 794 |           </li>
 795 |         </ul>
 796 |       </div>
 797 |       <section>
 798 |         <h3>
 799 |           Credential Protocols
 800 |         </h3>
 801 |         <p class="issue" title="Work in progress">
 802 |           Explain that while the API provides security at the browser API
 803 |           level, that security for the underlying credential issuance or
 804 |           presentation protocol is a separate concern and that developers need
 805 |           to understand that layer of the stack to get a total picture of the
 806 |           protections that are in place during any given transaction.
 807 |         </p>
 808 |       </section>
 809 |       <section>
 810 |         <h3>
 811 |           Cross-device Protocols
 812 |         </h3>
 813 |         <p class="issue" title="Work in progress">
 814 |           Explain that cross-device issuance or presentation uses a separate
 815 |           protocol that has its own security characteristics.
 816 |         </p>
 817 |       </section>
 818 |       <section>
 819 |         <h3>
 820 |           Quishing
 821 |         </h3>
 822 |         <p class="issue" title="Work in progress">
 823 |           Explain that the API is designed to avoid the problem of quishing
 824 |           (phishing via QR Codes) and other QR Code and non-browser API-based
 825 |           attacks and to be aware of exposure of QR Codes during digital
 826 |           credential interactions.
 827 |         </p>
 828 |       </section>
 829 |       <section>
 830 |         <h3>
 831 |           Data Integrity
 832 |         </h3>
 833 |         <p class="issue" title="Work in progress">
 834 |           Explain that the API does not provide data integrity on the digital
 835 |           credential requests or responses and that responsibility is up to the
 836 |           underlying protocol used for the request or response.
 837 |         </p>
 838 |       </section>
 839 |       <section>
 840 |         <h3>
 841 |           Authentication
 842 |         </h3>
 843 |         <p class="issue" title="Work in progress">
 844 |           Explain that authentication (such as a PIN code to unlock) to a
 845 |           particular app, such as a digital wallet, that responds to an API
 846 |           request is crucial in high-risk use cases.
 847 |         </p>
 848 |       </section>
 849 |       <section>
 850 |         <h3>
 851 |           Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF)
 852 |         </h3>
 853 |         <p class="issue" title="Work in progress">
 854 |           Explain what attacks are possible via XSS and CSRF, if any.
 855 |         </p>
 856 |       </section>
 857 |       <section>
 858 |         <h3>
 859 |           Session Security
 860 |         </h3>
 861 |         <p class="issue" title="Work in progress">
 862 |           Explain that once a secure session is established at a website using
 863 |           credentials exchanged over this API, that the subsequent security is
 864 |           no longer a function of the credential used or this API and is up to
 865 |           the session management utilized on the website.
 866 |         </p>
 867 |       </section>
 868 |     </section>
 869 |     <section class="informative">
 870 |       <h2>
 871 |         Privacy Considerations
 872 |       </h2>
 873 |       <div class="issue" title=
 874 |       "Privacy Considerations section is a work in progress">
 875 |         <p>
 876 |           This section is a work in progress as this document evolves.
 877 |         </p>
 878 |       </div>
 879 |       <p>
 880 |         The Digital Credentials API integrates into a complex ecosystem with
 881 |         multiple technology layers and various participants (including but not
 882 |         limited to Verifiers, Holders and Issuers), each of which have to
 883 |         consider different aspects of user privacy. This specification does not
 884 |         attempt to exhaustively list all considerations for the different
 885 |         participants. We would like to refer these parties to a variety of
 886 |         other resources that explore the digital credentials threat model more
 887 |         holistically:
 888 |       </p>
 889 |       <ul>
 890 |         <li>[[[credential-considerations]]]
 891 |         </li>
 892 |         <li>[[[threat-model-decentralized-identities]]]
 893 |         </li>
 894 |         <li>
 895 |           <a data-cite="vc-data-model#privacy-considerations">VC Data Model
 896 |           Privacy Considerations</a>
 897 |         </li>
 898 |         <li>...
 899 |         </li>
 900 |       </ul>
 901 |       <p>
 902 |         Instead, these considerations focus on the Digital Credentials API
 903 |         itself, and describe how user agents can satisfy their <a href=
 904 |         "https://w3ctag.github.io/privacy-principles/#dfn-user-agent-duties">user
 905 |         agent duties</a> in an implementation of the API, taking into account
 906 |         the relevant privacy properties of the ecosystem it interacts with.
 907 |       </p>
 908 |       <p>
 909 |         The privacy considerations for digital credentials are not static. They
 910 |         will evolve over time as the ecosystem matures, and may be informed by
 911 |         the behavior of other actors in the ecosystem, improvements in other
 912 |         layers of the stack, new threats to user privacy, as well as changing
 913 |         societal norms and regulations.
 914 |       </p>
 915 |       <p>
 916 |         It is expected that the various groups involved in the design and
 917 |         implementation of the Digital Credentials API actively monitor the
 918 |         evolving privacy landscape and participate in the corresponding
 919 |         evolution of the API.
 920 |       </p>
 921 |       <section data-cite="vc-data-model#spectrum-of-privacy">
 922 |         <h3>
 923 |           Spectrum of Privacy
 924 |         </h3>
 925 |         <p>
 926 |           The Digital Credentials API serves a variety of use cases with
 927 |           different grades of data disclosure and individual users with
 928 |           different preferences depending on the context that they are in.
 929 |           Notably, the privacy properties of a credential exchange mediated by
 930 |           this API could be mandated by the legal and regulatory environment of
 931 |           an individual user.
 932 |         </p>
 933 |         <p>
 934 |           This means that some users may not want, or be allowed, to use the
 935 |           most privacy-preserving means of exchanging credential information.
 936 |           Nonetheless, user agents need to serve users with an experience that
 937 |           is private by default and protect them from harm.
 938 |         </p>
 939 |         <p>
 940 |           Because of this spectrum of preferences and use cases, it may be
 941 |           difficult for a user agent to discern whether a user means to expose
 942 |           their personal information or is being tricked into doing so. It is
 943 |           thus the user agent's responsibility to ensure that every user
 944 |           understands what data they are sharing and who will participate in
 945 |           the exchange of information, before the exchange begins.
 946 |         </p>
 947 |       </section>
 948 |       <section>
 949 |         <h3>
 950 |           Unnecessary Requests for Credentials
 951 |         </h3>
 952 |         <p class="issue" title="Work in progress">
 953 |           Explain how the API could be used to unnecessarily request digital
 954 |           credentials from individuals such as requesting a driver's license to
 955 |           log into a movie rating website and how the ecosystem can mitigate
 956 |           this risk.
 957 |         </p>
 958 |       </section>
 959 |       <section>
 960 |         <h3>
 961 |           Over Collection of Data
 962 |         </h3>
 963 |         <p class="issue" title="Work in progress">
 964 |           Explain how the API could be used to request more data than necessary
 965 |           for a transaction and how the ecosystem can mitigate that over
 966 |           collection.
 967 |         </p>
 968 |       </section>
 969 |       <section>
 970 |         <h3>
 971 |           Individual Consent
 972 |         </h3>
 973 |         <p class="issue" title="Work in progress">
 974 |           Explain how the API acquires an individual's consent to share a
 975 |           digital credential and how digital wallets can also provide further
 976 |           consent when sharing information.
 977 |         </p>
 978 |       </section>
 979 |       <section>
 980 |         <h3>
 981 |           Data Retention
 982 |         </h3>
 983 |         <p class="issue" title="Work in progress">
 984 |           Explain how verifiers might retain data and what the ecosystem does
 985 |           to mitigate excessive data retention policies.
 986 |         </p>
 987 |       </section>
 988 |       <section>
 989 |         <h3>
 990 |           Compliance with Privacy Regulations
 991 |         </h3>
 992 |         <p class="issue" title="Work in progress">
 993 |           Explain to what extent the API complies with known privacy
 994 |           regulations (e.g., consent) and what parts of those regulations are
 995 |           not possible to enforce via the API (e.g., retention).
 996 |         </p>
 997 |       </section>
 998 |       <section>
 999 |         <h3>
1000 |           Selective and Unlinkable Disclosure
1001 |         </h3>
1002 |         <p class="issue" title="Work in progress">
1003 |           Explain how selective disclosure and unlinkable disclosure help
1004 |           preserve privacy as well as their limitations in doing so.
1005 |         </p>
1006 |       </section>
1007 |       <section>
1008 |         <h3>
1009 |           Phoning Home
1010 |         </h3>
1011 |         <p class="issue" title="Work in progress">
1012 |           Explain how some systems might "phone home", the impact on privacy
1013 |           that might have, and what the ecosystem provides to mitigate the
1014 |           risk.
1015 |         </p>
1016 |       </section>
1017 |       <section>
1018 |         <h3>
1019 |           Transmission of Personally Identifiable Information
1020 |         </h3>
1021 |         <p class="issue" title="Work in progress">
1022 |           Explain that the API does enable the transmission of personally
1023 |           identifiable information and that it does its best to ensure there is
1024 |           informed consent by the individual, but that the consent might be
1025 |           provided due to exhaustion or not understanding what PII is being
1026 |           transmitted and how to mitigate those concerns.
1027 |         </p>
1028 |       </section>
1029 |     </section>
1030 |     <section class="informative">
1031 |       <h2>
1032 |         Accessibility Considerations
1033 |       </h2>
1034 |       <p class="issue" title="Work in Progress">
1035 |         This section is a work in progress as this document evolves.
1036 |       </p>
1037 |     </section>
1038 |     <section id="idl-index"></section>
1039 |     <section id="conformance"></section>
1040 |   </body>
1041 | </html>
1042 | 


--------------------------------------------------------------------------------
/proposals/digital-credential-proposal.md:
--------------------------------------------------------------------------------
 1 | # ⚠️ This proposal has been superseded ⚠️
 2 | 
 3 | - Please refer to the [Digital identities spec](https://wicg.github.io/digital-identities/) instead. It represents the community's consensus.
 4 | 
 5 | ## Alternative proposal
 6 | 
 7 | This is an alternative design that further optimizes for decoupling federation and wallets (so that they have more autonomy to evolve independently),
 8 | while still accomplishing the goal of being able to request both at the same time in a single dialog.
 9 | 
10 | In this proposal, we create a new Credential Manager Credential type, say a DigitalCredential, as opposed to integrate with the existing 
11 | [IdentityCredential](https://fedidcg.github.io/FedCM/#browser-api-identity-credential-interface) type being used by FedCM.
12 | 
13 | > One of the unfortunate parts of this proposal is that FedCM is already built on top of IdentityCredential and the `identity` 
14 | > namespace in the Credential Manager API. 
15 | 
16 | ```javascript
17 | const result = await navigator.credentials.get({
18 |   digital: {
19 |     selector: {
20 |       format: ["mdoc"],
21 |       fields: [{
22 |         name: "doctype",
23 |         equals: "org.iso.18013.5.mDL"
24 |       }, {
25 |         name: "org.iso.18013.5.1.family_name"
26 |       }]
27 |     },
28 |     params: {
29 |       nonce: "1234",
30 |       readerPublicKey: "567",
31 |       anythingCanGoOverWhere: true
32 |     },
33 |   }
34 | });
35 | ```
36 | 
37 | Because the API is format agnostic, you'd be able to query VCs equally well:
38 | 
39 | ```javascript
40 | const result = await navigator.credentials.get({
41 |   digital: {
42 |     selector: [{
43 |       format: ["vc+sd-jwt"],
44 |       document: "UniversityDegreeCredential",
45 |       fields: [
46 |         "credentialSubject.dateOfBirth",
47 |         "credentialSubject.dob",
48 |         "vc.credentialSubject.dateOfBirth",
49 |         "vc.credentialSubject.dob",
50 |       ]
51 |     }],
52 |     params: {
53 |       nonce: "m5tGxUIsFtLi6pwg",
54 |     }
55 |   }
56 | });
57 | ``` 
58 | 
59 | The user agent can choose to fail this request if more than "dc" credentials are requested from the credential manager, as it normally would for 
60 | other credential types (e.g. you can't request a `publicKey` credential along with an `identity` or `otp` or a `password` credential at the moment).
61 | 
62 | If, and ever, we wanted to support querying wallets and federated identity providers at the same time, this is what it could look like:
63 | 
64 | ```javascript
65 | const result = await navigator.credentials.get({
66 |   digital: {
67 |     selector: {
68 |       format: ["mdoc"],
69 |       doctype: "org.iso.18013.5.mDL",
70 |       fields: ["org.iso.18013.5.1.family_name"]
71 |     },
72 |     params: {
73 |       nonce: "1234",
74 |       readerPublicKey: "567"
75 |     },
76 |   },
77 |   identity: {
78 |     providers: [{
79 |       configURL: "https://accounts.google.com/gsi/fedcm.json",
80 |       clientId: "212342",
81 |       nonce: "234231",
82 |     }]
83 |   }
84 | });
85 | ``` 
86 | 
87 | 


--------------------------------------------------------------------------------
/proposals/digital-credentials-2-proposal.md:
--------------------------------------------------------------------------------
 1 | # ⚠️ This proposal has been superseded ⚠️
 2 | 
 3 | - Please refer to the [Digital identities spec](https://wicg.github.io/digital-identities/) instead. It represents the community's consensus
 4 | 
 5 | ## Towards a preliminary API to retrieve Digital Credentials
 6 | 
 7 | Digital identities encompass a range of use cases, from age verification to sharing verifiable identity proofs, along with numerous other credential types. Managing and retrieving these identities is complicated by the varied formats in which they exist. A standardized approach, adaptable to diverse identity formats is essential for the Web, as it's expected that this API will be used in an extensive range of jurisdictions (which in turn may use different credential representation and retrieval standards). Moreover, such an approach must prioritize user privacy and guarantee robust security while allowing sites to verify the credentials they request and receive while keeping users in control over what, when, and with who, is share.
 8 | 
 9 | This document presents an API solution designed to deal with the varying digital identity formats. The API builds on the existing W3C Credential Management API and focuses on upholding user privacy and ensuring comprehensive data protection, streamlining the digital identity experience for all users.
10 | 
11 | ## Why leverage Credential Management API
12 | 
13 | The Credential Management API is well positioned as the foundation for our proposed solution. True to its name, this API was designed with the concept of "credentials" at its core, specifically how these credentials are managed.
14 | 
15 | Of even greater significance, the API seamlessly integrates with the web's security model. It's designed to delegate the user experience to the browser, such as presenting digital wallet(s) from which users can select a requested credential. The specification is designed to be extensible, with comprehensive integration points. Each of these points has customizable security properties, like requiring a user gesture or being callable only from a top-level browsing context, to name a few.
16 | 
17 | However, given its initial design orientation towards password-style credentials, we believe some modifications to the Credential Management API are in order to optimize it for handling identity credentials.
18 | 
19 | ## Extensions to Credential Management API: `requestIdentity()` method
20 | 
21 | We propose extending the `CredentialsContainer` interface with a new method: `requestIdentity()`. Unlike the existing .get() method, this new method is crafted to improve the retrieval and management of digital identities.
22 | 
23 | The rationale for introducing a new method, instead of using the existing .get(), is as follows:
24 | 
25 | - **Structured Requests**: The proposed `requestIdentity()` method is designed to accept a sequence of `IdentityRequestOptions` (discussed in more details below). This dictionary type is purposefully conceived to meet the specialized requirements of requesting identity credentials.
26 | - **Clear Differentiation**: With `requestIdentity()`, we aim to prevent potential mix-ups between different request types, offering a clear distinction between tasks such as password retrieval and age verification (which could happen with using just the `.get()`method).
27 | - **Developer Intuition**: Through the naming of `requestIdentity()`, we anticipate offering developers immediate clarity that an identity is being solicited.
28 | - **Enhanced Flexibility**: `requestIdentity()`, as proposed, is designed with adaptability in mind, allowing for potential expansions and adjustments in line with future requirements.
29 | - **Security Integrity**: As a suggested extension to the `CredentialsContainer`, the `requestIdentity()` method would inherit the robust security features of the Credential Management infrastructure.
30 | - **Efficient Underpinnings**: At its core, `requestIdentity()` is intended to serve as a specialized wrapper around the existing `.get()` method, addressing its inherent limitations, particularly its challenges with type distinctions.
31 | - **Storage Limitations**: An essential aspect of our proposal is to underline that `requestIdentity()` would focus exclusively on retrieval and would not encompass mechanisms for credentials storage. This may change in the future, but right now we only deal with identity credential retrieval.
32 | 
33 | The API extension would be:
34 | 
35 | ```WebIDL
36 | partial interface CredentialsContainer {
37 |  Promise<DigitalCredential> requestIdentity(IdentityRequestOptions options);
38 | };
39 | ```
40 | 
41 | ## The `IdentityRequestOptions` dictionary
42 | 
43 | The `IdentityRequestOptions` dictionary would be specifically designed to handle requests in a "protocol" agnostic manner, while also handling cryptographic requirements. We envision a "protocol" member serving to identify the standard being used to make the request (e.g.,"OpenID4VP", "mDoc", etc). The request itself would likely just be a string, and the dictionary would need some means to pass along a public key.
44 | 
45 | The above expresses as WebIDL would be:
46 | 
47 | ```WebIDL
48 | dictionary IdentityRequestOptions {
49 |  AbortSignal signal; // tears down the UI, if needed.
50 |  required sequence<IdentityRequestProvider> providers;
51 | };
52 | 
53 | dictionary IdentityRequestProvider {
54 |  required DOMString protocol; // See "Protocol Registry" below
55 |  required DOMString request;
56 |  required DOMString publicKey;
57 |  // Other members
58 | };
59 | ```
60 | 
61 | What other members would be included in both dictionaries is up for discussion (e.g., nonce, reason for request, etc.).
62 | 
63 | ## The `DigitalCredential` interface
64 | 
65 | An "digital credential" is the result from the promise resolving as a result of calling the .requestIdentity() method. We envision this interface exposing a read-only `.response` attribute, which would contain the encrypted response for the corresponding request.
66 | 
67 | Our expectation is that all responses are encrypted by default.
68 | 
69 | ```WebIDL
70 | [Exposed=Window, SecureContext]
71 | interface DigitalCredential {
72 |   [SameObject] readonly attribute ArrayBuffer response;
73 | };
74 | ```
75 | 
76 | ## Registry of credential identity protocols
77 | 
78 | This would be a simple registry to help identify which "protocol" is being used to make a request (i.e. a string identifying the standard, and its request format, which the browser or OS can then use to locate the requested identity credential).
79 | 
80 | Following in the tradition of the Web, we hope to make this registry open and developer friendly. For instance, "OpenID for Verifiable Presentations" might be identified as "`OpenID4VP`" and perhaps "ISO/IEC 18013-5:2021" could simply be identified as "mDL" (mobile drivers license), and so on.
81 | 
82 | The registry would likely be a W3C “[_Registry Track_](https://www.w3.org/2023/Process-20230612/#registries)" document so the Web community can make sure that, in order to be included, a standard meets privacy, security, and usability expectations.
83 | 


--------------------------------------------------------------------------------
/proposals/identity-credential-proposal.md:
--------------------------------------------------------------------------------
  1 | # ⚠️ This proposal has been superseded ⚠️
  2 | 
  3 | - Please refer to the [Digital identities spec](https://wicg.github.io/digital-identities/) instead. It represents the community's consensus.
  4 | 
  5 | ## Identity Credential
  6 | 
  7 | ## Problem
  8 | 
  9 | There are multiple ways to present credentials on the web, and more being proposed. It may be that some use cases (like age verification or university affiliation) will be able to be met by multiple different approaches, but existing API designs could mean that users are forced to choose which technology to use without necessarily having the context to easily make that choice. Eg. websites might be forced to present options like "Click here to prove your employer with the identity in your wallet app" and "Click here to login to your company's server to prove your employment". It seems there's an opportunity to create some common groundwork now which could help enable websites to more often simply say "Click here to prove your employer" and let the browser and OS figure out what options are best presented for this specific user.
 10 | 
 11 | ## Proposal 
 12 | 
 13 | This document contains an explainer for `IdentityCredential`—a credential type in the [Credential Management](https://www.w3.org/TR/credential-management-1/) framework for all types of identity verification. Types of identity credentials would extend `IdentityCredential` in the same way that different authentication methods extend [Credential Management](https://www.w3.org/TR/credential-management-1/) today.
 14 | 
 15 | <img src="./structure.svg" alt="Diagram of API structure" width="300px">
 16 | 
 17 | In this proposal, we lift `IdentityCredential` out of [Federated Credential Management](https://fedidcg.github.io/FedCM/) (FedCM). FedCM would be one extension of `IdentityCredential` but user agents would not need to implement FedCM in order to support other types of identity credentials.
 18 | 
 19 | This proposal is informed by a few design points:
 20 | 
 21 | 1. identity credentials are going to come in multiple formats, determined in part by legislation and non-web standards
 22 | 1. some browsers may choose to be largely agnostic to the credential format, acting mostly as a conduit for the underlying platform or wallet applications
 23 | 1. identity verification is not authentication
 24 | 
 25 | First, `IdentityCredential` supports multiple identity verification schemes because we envision that sites may want to support multiple identity types in a single identity credential picker while retaining some influence over the order in which they are presented to the user.
 26 | 
 27 | For example, student university affiliations are often asserted via [SAML](https://www.oasis-open.org/committees/download.php/56776/sstc-saml-core-errata-2.0-wd-07.pdf) today, but student IDs are going to be increasingly made available in wallet apps ([example](https://www.purdue.edu/newsroom/releases/2023/Q2/purdue-launches-purdue-mobile-id-for-students-allowing-them-to-get-around-campus-with-just-a-simple-tap-of-their-mobile-device.html)) and so could be verifiable credentials (e.g. [mdocs](https://www.ul.com/resources/new-isoiec-standard-electronic-credentials) or [W3C VCs](https://www.w3.org/TR/vc-data-model/)) in the future. An online library (e.g. nature.com) that needs users to prove their student affiliations may need to support both mdocs and federation in order to support students from multiple institutions.
 28 | 
 29 | Second, we think it is key to make requests for identity verification different from requests for authentication. The former is (potentially) a much more significant operation because it may disclose an irrevocable, cross-site identity. Because of this we considered building a `navigator.identity` namespace but ultimately decided to use [Credential Management](https://www.w3.org/TR/credential-management-1/), and thus `navigator.credentials`. This was because FedCM already uses `navigator.credentials.get({identity: …})` and thus the term `identity` would appear twice in the Web Platform if `navigator.identity` was added. But the use of `identity` for `IdentityCredential` was not a mistake: federation, and thus FedCM, provides identity verification and over time we would like authentication to be handled by [`PublicKeyCredential`](https://www.w3.org/TR/webauthn-2/#iface-pkcredential) (e.g. &ldquo;passkeys&rdquo;). However, today, FedCM is used for authentication too and so it lives in `navigator.credentials`. 
 30 | 
 31 | Thus we want to support identity requests that can be satisfied by either mdocs or federation, and authentication requests that can be satisfied by either passwords, passkeys, or federation. This implies that all those mechanisms end up in `navigator.credentials` and that has informed this design.
 32 | 
 33 | All identity requests are grouped together, rather than made top-level types in Credential Management, to communicate that they are separate from the authentication mechanisms. In general, user agents that receive a request that combines authentication and identity verification, e.g. a request for either an mdoc or a passkey, SHOULD immediately reject such requests with a `NotSupportedError` exception.
 34 | 
 35 | ## The IdentityCredential Interface
 36 | 
 37 | `IdentityCredential` is a new type of [Credential](https://w3c.github.io/webappsec-credential-management/#credential):
 38 | 
 39 | ```webidl
 40 | [Exposed=Window, SecureContext]
 41 | interface IdentityCredential : Credential {
 42 |   readonly attribute USVString? token;
 43 | };
 44 | ```
 45 | 
 46 | [CredentialRequestOptions](https://w3c.github.io/webappsec-credential-management/#dictdef-credentialrequestoptions) is extended with a new member for identity requests:
 47 | 
 48 | ```webidl
 49 | partial dictionary CredentialRequestOptions {
 50 |   IdentityCredentialRequestOptions identity;
 51 | };
 52 | ```
 53 | 
 54 | `IdentityCredentialRequestOptions` mirrors the pattern of Credential Management and is extended with a list of identity verification providers:
 55 | 
 56 | ```webidl
 57 | dictionary IdentityCredentialRequestOptions {
 58 |   // Common request fields, e.g. the context API.
 59 | 
 60 |   sequence<IdentityProviderConfig> providers;
 61 | }
 62 | ```
 63 | 
 64 | `IdentityProviderConfig` represents a scheme-specific source of identity credentials, and it expected to be extended by other specifications (e.g. the federated or mdocs scheme).
 65 | 
 66 | ```
 67 | dictionary IdentityProviderConfig {
 68 |   // More common fields across all identity provider types:
 69 |   // ...
 70 | };
 71 | ```
 72 | 
 73 | As an illustrative example, the definition of an identity scheme would add members to that dictionary:
 74 | 
 75 | ```webidl
 76 | partial dictionary IdentityProviderConfig {
 77 |   WalletProvider holder;
 78 | }
 79 | 
 80 | dictionary WalletProvider {
 81 |   // A query selector that is used by wallets to filter credentials for
 82 |   // selection.
 83 |   WalletSelector selector;
 84 | 
 85 |   // An opaque map of parameters sent to wallets upon selection.
 86 |   record<USVString, USVString> params;
 87 | };
 88 | 
 89 | dictionary WalletSelector {
 90 |   // A list of desired formats for the credential.
 91 |   sequence<USVString> format;
 92 |   // The top-level type of document (e.g. a passport, driver's license, etc).
 93 |   DOMString doctype;
 94 |   // The amount of time the verifier intends to retain the credential.
 95 |   // Omitting `retention` implies that the identity information will not be stored.
 96 |   // How long the verifier intends to retent the credential.
 97 |   WalletStorageDuration retention;
 98 |   // The requested fields.
 99 |   sequence<(WalletFieldRequirement or DOMString)> fields;
100 | };
101 | 
102 | dictionary WalletFieldRequirement {
103 |   required DOMString name;
104 |   DOMString equals;
105 | };
106 | 
107 | dictionary WalletStorageDuration {
108 |   // Exactly one of the following must be provided.
109 |   boolean forever;
110 |   long days;
111 | };
112 | ```
113 | 
114 | When [DiscoverFromExternalSource](https://w3c.github.io/webappsec-credential-management/#dom-credential-discoverfromexternalsource-slot) is invoked, the `DiscoverFromExternalSource` function of each of the different identity providers  specified in the `IdentityCredentialRequestOptions.providers` is run in parallel. If any throws an error then that error is the result of `IdentityCredential`'s DiscoverFromExternalSource. If one or more return an `IdentityCredential` then the user agent picks one of the values as the result, as its discretion. Otherwise the result is `null`.
115 | 
116 | ## Examples
117 | 
118 | These are examples of extensions to `IdentityCredential` that we would expect, and how / why they'd fit together.
119 | 
120 | - [mdocs](#mdocs)
121 | - [FedCM](#fedcm)
122 | - [W3C Verifiable Credentials](#w3c-verifiable-credentials)
123 | 
124 | ### MDocs
125 | 
126 | The [MDocs API](https://github.com/agl/mobile-document-request-api/tree/identityapi#examples) extends the `IdentityCredential` API to allow mdocs to be requested:
127 | 
128 | ```js
129 | // Gets a CBOR with specific fields out of mobile driver's license as an mdoc
130 | const {response} = await navigator.credentials.get({
131 |   identity: {
132 |     providers: [{
133 |       holder: {
134 |         selector: {
135 |           retention: {days: 90},
136 |           doctype: "org.iso.18013.5.1.mDL",
137 |           fields: [
138 |             "org.iso.18013.5.1.document_number",
139 |             "org.iso.18013.5.1.portrait",
140 |             "org.iso.18013.5.1.driving_privileges",
141 |             "org.iso.18013.5.1.aamva.organ_donor",
142 |           ],
143 |         },
144 |         params: {
145 |           nonce: "gf69kepV+m5tGxUIsFtLi6pwg=",
146 |           readerPublicKey: "ftl+VEHPB17r2 ... Nioc9QZ7X/6w...",
147 |         }
148 |       }
149 |     }],
150 |   }
151 | });
152 | ```
153 | 
154 | ### FedCM
155 | 
156 | The [FedCM](https://fedidcg.github.io/FedCM/) also extends the `IdentityCredential` API to provide a binding to [OpenID](https://openid.net/specs/openid-connect-core-1_0.html) and [SAML](https://seamlessaccess.org/posts/2023-02-20-fedcm/): 
157 | 
158 | ```js
159 | // Gets a JWT from a OIDC provider. 
160 | const {response} = await navigator.credentials.get({
161 |   identity: {
162 |     providers: [{
163 |       federated: {
164 |         configURL: "https://university.edu/students",
165 |         clientId: "123",
166 |         nonce: "m5tGxUIsFtLi6pwg"
167 |       }
168 |     }]
169 |   }
170 | }
171 | ```
172 | 
173 | ### W3C Verifiable Credentials
174 | 
175 | We also expect that we'd at some point extend `IdentityCredential` to provide a binding to [CHAPI](https://github.com/fedidcg/FedCM/issues/374) and [OIDC4VP](https://openid.net/specs/openid-connect-4-verifiable-presentations-1_0-07.html).
176 | 
177 | While this is still something that we are actively exploring with that community ([example](https://w3c-ccg.github.io/meetings/2023-01-24/) and early [proposal](https://github.com/fedidcg/FedCM/issues/374)), here is a possible example of what that could look like:
178 | 
179 | > It is worth noting how closely related this looks to the [mdocs](#mdocs) extension.
180 | 
181 | ```js
182 | // Gets a SD-JWT from a W3C VC holder.
183 | const {response} = await navigator.credentials.get({
184 |   identity: {
185 |     providers: [{
186 |       holder: {
187 |         format: ["vc+sd-jwt"],
188 |         selector: [{
189 |           doctype: "UniversityDegreeCredential",
190 |           fields: [        
191 |             "credentialSubject.dateOfBirth",
192 |             "credentialSubject.dob",
193 |             "vc.credentialSubject.dateOfBirth",
194 |             "vc.credentialSubject.dob",                     
195 |           ]
196 |         }],
197 |         params: {
198 |           nonce: "m5tGxUIsFtLi6pwg",
199 |         }
200 |       },
201 |     }]
202 |   }
203 | }
204 | ```
205 | 
206 | ### Reconcilation
207 | 
208 | User agents can support multiple identity schemes, and they can be requested at the same time:
209 | 
210 | ```js
211 | // Requests a verifiable affilitation to a university, accepting mdocs,
212 | // W3C VCs and SAML assertions.
213 | const credential = await navigator.credentials.get({
214 |   identity: {
215 |     // Requests the user's university affiliation from either 
216 |     // a W3C VC, an MDoc or a JWT.
217 |     providers: [{
218 |       // The university may have a device-bound certificate ...
219 |       holder: {
220 |         selector: {
221 |           retention: {days: 90},
222 |           doctype: "org.iso.18013.5.1.UniversityDegree",
223 |           fields: [
224 |             "org.iso.18013.5.1.affiliation",
225 |           ],
226 |         },
227 |         params: {
228 |           nonce: "1234",
229 |           readerPublicKey: "...ftl+VEHpdNioc9QZ7X/6w...",
230 |         },
231 |       }
232 |     }, {
233 |       // ... or a SAML assertion ...
234 |       federated: {
235 |         clientId: "myapp",
236 |         nonce: "1234",
237 |         configURL: "https://idp.university.edu",
238 |       }
239 |     }, {
240 |       // ... or a Verifiable Credential ...
241 |       holder: {
242 |         selector: {
243 |           doctype: "UniversityDegreeCredential",
244 |           fields: [
245 |               "credentialSubject.alumniOf",                 
246 |           ]
247 |         }
248 |       },
249 |     }]
250 |   }
251 | });
252 | 
253 | ```
254 | 


--------------------------------------------------------------------------------
/proposals/mobile-document-request-api-proposal.md:
--------------------------------------------------------------------------------
  1 | # ⚠️ This proposal has been superseded ⚠️
  2 | 
  3 | - Please refer to the [Digital identities spec](https://wicg.github.io/digital-identities/) instead. It represents the community's consensus.
  4 | 
  5 | ## Mobile Document Request API
  6 | 
  7 | ## Authors
  8 | 
  9 | - [@dcrousso](https://github.com/dcrousso)
 10 | - [@hlozi](https://github.com/hlozi)
 11 | - [@martijnharing](https://github.com/martijnharing)
 12 | 
 13 | 
 14 | ## Participate
 15 | 
 16 | - [Issue tracker](https://github.com/WICG/mobile-document-request-api/issues)
 17 | 
 18 | 
 19 | ## Introduction
 20 | 
 21 | This is a proposal for a new web API that allows websites to request a mobile document as defined in ISO/IEC 18013-5 using structures defined in the same ISO in order to achieve an online presentment. The API would protect the mobile document credential data, supports selective disclosure, and allow the user to control the release of credential data.
 22 | 
 23 | The ISO/IEC 18013-5:2021 standard specifies how a driver license (mDL) is represented on a mobile device and how it is presented to a physical reader.  Users who chose to have their mDL on device can present it to compatible readers instead of the physical driver license.  The ISO standard defines the protocols and the exchanges between the mDL and the mDL reader for different physical uses case (e.g. TSA, Hotel, store,... ).  The ISO standard provides building blocks to allow remote presentment of the the mobile driver’s license over the Web such as data structures and operational phases.  The ISO standard ISO/IEC 18013-5:2021 for mobile driver’s license does not define a web API to allow presentement via user agent.
 24 | 
 25 | The mechanisms defined by ISO/IEC 18013-5 are designed to support any type of mobile document, called mdoc. Besides the mDL, this API can therefore be used to request and transmit any mobile document that implements the ISO mdoc specification.
 26 | 
 27 | 
 28 | 
 29 | ## Goals
 30 | 
 31 | - Allow websites to request the presentment of a mobile document in mdoc format such as driver’s license. 
 32 | - Enable the user to have a consent based control of what data is released to the website. 
 33 | - Protect the released data using encryption to ensure only the website the data is intended for can access the data.
 34 | 
 35 | 
 36 | ## Non-goals
 37 | 
 38 | - Define issuance and provisioning of an mdoc.
 39 | - Define the communication between the User Agent and the website server is out of scope. 
 40 | - Define the native communication between the User Agent and the application holding the mdoc.
 41 | - Define how the response to the request is used by the server is out of scope. 
 42 | - Requesting multiple mdocs in one API call.
 43 | 
 44 | 
 45 | ## Proposed Solution
 46 | 
 47 | The API request should contain all the information needed to build up and encrypt the response.  The response data from the mdoc should be a CBOR-encoded blob encrypted end-to-end for the intended relying party using Hybrid Public Key Encryption (HPKE) defined in RFC 9180.  Only the targeted relying party, holder of the private part corresponding to the public key used for the response encryption, should be able to decrypt the response (with the assumption that the server always holds and protects the  private key).  The API should allow the server to pass as a parameter a requester identity object that allows the mdoc device to extract the public key material needed for the encryption.  The passed object can be anything that allows the mdoc to determine which public key to encrypt the response to, like a certificate, a key or a key identifier.
 48 | 
 49 | 
 50 | ### Request
 51 | 
 52 | The website would need to provide a document type and desired data elements, as well as a requester identity object that allows the device to extract the encryption public key (and the mdoc to optionally verify the eligibility of the website to request the mdoc presentment).
 53 | 
 54 | Once mdoc application verifies the server identity object to make sure it is a legitimate request (if needed), it would build up the response according to ISO/IEC 18013-5, including the credential data itself, the authentication by the issuer, and the authentication by the device, encrypting everything with the key derived from the requester identity object using HKPE so that only the server can decrypt the binary blob (assuming the server keeps and protects the private key).
 55 | 
 56 | After sending the encrypted data to the server, it would be decrypted to verify the presented mdoc issuer signature and device signature according to ISO/IEC 18013-5.
 57 | 
 58 | 
 59 | ### Response
 60 | 
 61 | The response from the server would be the `DeviceResponse` object as defined in ISO/IEC 18013-5 clause 8.3.2.1.2.2 encoded with CBOR according to ISO/IEC 18013-5, encrypted using HPKE with the following settings:
 62 | ```
 63 | mode: mode_base
 64 | KEM: DHKEM(P-256, HKDF-SHA256)
 65 | KDF: HKDF-SHA256
 66 | AEAD: AES-128-GCM
 67 | ```
 68 | 
 69 | Part of the signature generated for `DeviceAuth` is done using the `SessionTranscript` structure as defined in ISO/IEC 18103-5 section 9.1.5.1.  The `DeviceEngagementBytes` and the `EReaderKeyBytes` are both not present, and therefore have a value of `null`.  The `Handover` element shall be as defined below:
 70 | ```
 71 | BrowserHandover = [
 72 |     "BrowserHandoverv1",
 73 |     Nonce,
 74 |     OriginInfoBytes,
 75 |     RequesterIdentity,
 76 |     pkEm
 77 | ]
 78 | ```
 79 | where `Nonce` is the nonce provided by the request, `OriginInfoBytes` contains the origin of the request and is defined in ISO/IEC 18013-7, and `RequesterIdentity` is the requester identity object from the request.
 80 | 
 81 | This is all included inside a CBOR encoded `CredentialDocument` with the following structure:
 82 | ```
 83 | CredentialDocument = {
 84 |     "version": tstr,
 85 |     "encryptionParamaters": EncryptionParamaters,
 86 |     "data": bstr
 87 | }
 88 | 
 89 | EncryptionParamaters = {
 90 |     "version": tstr,
 91 |     "EDeviceKey": bstr,
 92 |     "originInfoBytes": OriginInfoBytes
 93 | }
 94 | ```
 95 | 
 96 | 
 97 | ### API
 98 | 
 99 | One idea a new `CredentialRequest` (et al)
100 | ```
101 | dictionary CredentialElement {
102 |     required DOMString namespace;  // As defined in ISO 18013-5 clause 8.
103 |     required DOMString name;
104 | };
105 | 
106 | dictionary CredentialStorageDuration {
107 |     // At least one of these is required.
108 | 
109 |     boolean forever;  // Cannot be used with any other properties.
110 | 
111 |     long days;  // Cannot (currently) be used with any other properties.
112 | };
113 | 
114 | dictionary CredentialDocumentDescriptor {
115 |     required DOMString documentType;  // As defined in ISO 18013-5 clause 8.
116 | 
117 |     required sequence<CredentialElement> requestedElements;
118 | 
119 |     CredentialStorageDuration desiredStorageDuration;  // Not providing this is equivalent to not asking to store.
120 | };
121 | 
122 | dictionary CredentialDocument {
123 |     object data;  // The CBOR encoded `CredentialDocument` defined above.
124 | };
125 | 
126 | dictionary RequestConfiguration {
127 |     required DOMString nonce;
128 | };
129 | 
130 | [
131 |     SecureContext,
132 |     Exposed=Window,
133 | ] interface CredentialRequest {
134 |     constructor(DOMString requesterIdentity, CredentialDocumentDescriptor documentDescriptor);  // This throws if anything in the `documentDescriptor` is not recognized (e.g. an invalid `documentType`).
135 | 
136 |     Promise<CredentialDocument> requestDocument(RequestConfiguration configuration);
137 | 
138 |     Promise<undefined> abort();
139 | };
140 | ```
141 | 
142 | 
143 | ## Examples
144 | 
145 | ```js
146 | // Driver's License
147 | let mDLCredentialRequest = new CredentialRequest(certificate, {
148 |     documentType: "org.iso.18013.5.1.mDL",
149 |     requestedElements: [
150 |         { namespace: "org.iso.18013.5.1", name: "document_number" },
151 |         { namespace: "org.iso.18013.5.1", name: "portrait" },
152 |         { namespace: "org.iso.18013.5.1", name: "driving_privileges" },
153 |         { namespace: "org.iso.18013.5.1.aamva", name: "organ_donor" },
154 |         { namespace: "org.iso.18013.5.1.aamva", name: "hazmat_endorsement_expiration_date" },
155 |     ],
156 |     desiredStorageDuration: {
157 |         days: 7,
158 |     },
159 | });
160 | mDLCredentialRequest.request({ nonce }).then((credentialDocument) => { ... });
161 | ```
162 | 
163 | ```js
164 | // Vaccination Card
165 | let micovCredentialRequest = new CredentialRequest(certificate, {
166 |     documentType: "org.micov.1",
167 |     requestedElements: [
168 |         { namespace: "org.micov.attestation.1", name: "PersonId_dl" },
169 |         { namespace: "org.micov.attestation.1", name: "portrait" },
170 |     ],
171 | });
172 | micovCredentialRequest.request({ nonce }).then((credentialDocument) => { ... });
173 | ```
174 | 
175 | 
176 | ## Privacy & Security Considerations
177 | 
178 | This API provides the ability for websites to retrieve an ISO 18013-5 mDoc already on the device.  An important part of the security and privacy mechanisms are provided by ISO 18013-5:
179 | - Protection against forgery with passive data authentication defined in ISO 18013-5 based on Mobile Security Object (MSO).
180 | - Protection against cloning using active authentication leveraging a signature over session data.  The signature is produced by the device using the device private key as defined in ISO 18013-5.  The Device Public key is part of the MSO signed by the issuer.
181 | - The ability for the user to see the requested data before disclosure, in addition to being able to choose what to disclose.
182 | - The ability for the website to request a subset of data, rather than any sort of all-or-nothing.
183 | - Protection against eavesdropping during transactions by using HPKE to encrypt the response containing the mDoc to the requesting server.
184 | - Man in the middle attacks are detectable by the requesting server via validation of the device signature over session data.
185 | 
186 | 
187 | ## References & acknowledgements
188 | 
189 | Many thanks for valuable feedback and advice from:
190 | 
191 | - [@15characterlimi](https://github.com/15characterlimi)
192 | - [@agl](https://github.com/agl)
193 | - [@balfanz](https://github.com/balfanz)
194 | - [@bslassey](https://github.com/bslassey)
195 | - [@cwilso](https://github.com/cwilso)
196 | - [@davidz25](https://github.com/davidz25)
197 | - [@divegeek](https://github.com/divegeek)
198 | - [@hober](https://github.com/hober)
199 | - [@jyasskin](https://github.com/jyasskin)
200 | - [@samuelgoto](https://github.com/samuelgoto)
201 | - [@sethmoo](https://github.com/sethmoo)
202 | 


--------------------------------------------------------------------------------
/proposals/navigator-identity-proposal.md:
--------------------------------------------------------------------------------
 1 | # ⚠️ This proposal has been superseded ⚠️
 2 | 
 3 | - Please refer to the [Digital identities spec](https://wicg.github.io/digital-identities/) instead. It represents the community's consensus.
 4 | 
 5 | ## Alternate design
 6 | 
 7 | This is an alternative design that further optimizes the decoupling of identity verification and authentication (so that developers get a clear signal about their differences), while still accomplishing the goal of being able to request multiple identity schemes (e.g., mdocs, vcs, and federation) at the same time in a single dialog.
 8 | 
 9 | In this proposal, we create a new namespace for identity verification, say `navigator.identity`, as opposed to integrate with the existing 
10 | authentication-oriented [Credential Manager](https://www.w3.org/TR/credential-management-1/) being used by WebAuthn, WebOTP and FedCM.
11 | 
12 | > NOTE: an alternative (and compatible) variation is to introduce a `navigator.credentials.getIdentity()` method that has the same structure as this.
13 | 
14 | ```javascript
15 | const result = await navigator.identity.get({
16 |   dc: {
17 |     selector: {
18 |       format: ["mdoc"],
19 |       doctype: "org.iso.18013.5.mDL",
20 |       fields: ["org.iso.18013.5.1.family_name"]
21 |     },
22 |     params: {
23 |       nonce: "1234",
24 |       readerPublicKey: "567"
25 |     },
26 |   }
27 | });
28 | ``` 
29 | 
30 | >  NOTE: should / how would we factor in here federated identities?
31 | 
32 | In this variation, there is no API affordance for a developer to make the mistake of requesting identity verification and authentication mechanisms
33 | at the same time.
34 | 


--------------------------------------------------------------------------------
/proposals/structure.svg:
--------------------------------------------------------------------------------
1 | <svg version="1.1" viewBox="0.0 0.0 297.04461942257217 320.0551181102362" fill="none" stroke="none" stroke-linecap="square" stroke-miterlimit="10" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg"><clipPath id="p.0"><path d="m0 0l297.04462 0l0 320.0551l-297.04462 0l0 -320.0551z" clip-rule="nonzero"/></clipPath><g clip-path="url(#p.0)"><path fill="#000000" fill-opacity="0.0" d="m0 0l297.04462 0l0 320.0551l-297.04462 0z" fill-rule="evenodd"/><path fill="#cfe2f3" d="m0 316.76642l0 -316.75592l42.80315 0l0 316.75592z" fill-rule="evenodd"/><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m0 316.76642l0 -316.75592l42.80315 0l0 316.75592z" fill-rule="evenodd"/><path fill="#000000" d="m23.634073 246.97739l0.453125 -1.765625q2.171875 0.5625 3.328125 2.0q1.140625 1.4375 1.140625 3.53125q0 2.15625 -0.875 3.515625q-0.890625 1.34375 -2.546875 2.0625q-1.671875 0.703125 -3.59375 0.703125q-2.078125 0 -3.625 -0.796875q-1.5625 -0.796875 -2.359375 -2.265625q-0.8125 -1.484375 -0.8125 -3.25q0 -2.0 1.015625 -3.359375q1.015625 -1.375 2.875 -1.90625l0.40625 1.734375q-1.453125 0.46875 -2.109375 1.359375q-0.671875 0.875 -0.671875 2.203125q0 1.546875 0.734375 2.578125q0.734375 1.03125 1.984375 1.453125q1.234375 0.421875 2.5625 0.421875q1.703125 0 2.96875 -0.5q1.265625 -0.5 1.90625 -1.546875q0.625 -1.046875 0.625 -2.265625q0 -1.484375 -0.859375 -2.515625q-0.859375 -1.03125 -2.546875 -1.390625zm4.6875 -3.7229462l-9.671875 0l0 -1.46875l1.46875 0q-1.03125 -0.5625 -1.359375 -1.03125q-0.328125 -0.484375 -0.328125 -1.0625q0 -0.828125 0.53125 -1.6875l1.515625 0.5625q-0.359375 0.609375 -0.359375 1.203125q0 0.546875 0.328125 0.96875q0.328125 0.421875 0.890625 0.609375q0.875 0.28125 1.921875 0.28125l5.0625 0l0 1.625zm-3.109375 -12.853302l0.203125 -1.6875q1.484375 0.40625 2.3125 1.484375q0.8125 1.078125 0.8125 2.765625q0 2.125 -1.296875 3.375q-1.3125 1.234375 -3.671875 1.234375q-2.453125 0 -3.796875 -1.25q-1.34375 -1.265625 -1.34375 -3.265625q0 -1.9375 1.328125 -3.15625q1.3125 -1.234375 3.703125 -1.234375q0.15625 0 0.4375 0l0 7.21875q1.59375 -0.09375 2.453125 -0.90625q0.84375 -0.8125 0.84375 -2.015625q0 -0.90625 -0.46875 -1.546875q-0.484375 -0.640625 -1.515625 -1.015625zm-2.65625 5.390625l0 -5.40625q-1.21875 0.109375 -1.828125 0.625q-0.953125 0.78125 -0.953125 2.03125q0 1.125 0.765625 1.90625q0.75 0.765625 2.015625 0.84375zm5.765625 -15.406967l-1.21875 0q1.4375 0.90625 1.4375 2.703125q0 1.15625 -0.640625 2.125q-0.640625 0.96875 -1.78125 1.5q-1.140625 0.53125 -2.625 0.53125q-1.453125 0 -2.625 -0.484375q-1.1875 -0.484375 -1.8125 -1.4375q-0.625 -0.96875 -0.625 -2.171875q0 -0.875 0.375 -1.546875q0.359375 -0.6875 0.953125 -1.109375l-4.796875 0l0 -1.640625l13.359375 0l0 1.53125zm-4.828125 5.171875q1.859375 0 2.78125 -0.78125q0.921875 -0.78125 0.921875 -1.84375q0 -1.078125 -0.875 -1.828125q-0.890625 -0.75 -2.6875 -0.75q-1.984375 0 -2.90625 0.765625q-0.9375 0.765625 -0.9375 1.890625q0 1.078125 0.890625 1.8125q0.890625 0.734375 2.8125 0.734375zm1.71875 -15.906967l0.203125 -1.6875q1.484375 0.40625 2.3125 1.484375q0.8125 1.078125 0.8125 2.765625q0 2.125 -1.296875 3.375q-1.3125 1.234375 -3.671875 1.234375q-2.453125 0 -3.796875 -1.25q-1.34375 -1.265625 -1.34375 -3.265625q0 -1.9375 1.328125 -3.15625q1.3125 -1.234375 3.703125 -1.234375q0.15625 0 0.4375 0l0 7.21875q1.59375 -0.09375 2.453125 -0.90625q0.84375 -0.8125 0.84375 -2.015625q0 -0.90625 -0.46875 -1.546875q-0.484375 -0.640625 -1.515625 -1.015625zm-2.65625 5.390625l0 -5.40625q-1.21875 0.109375 -1.828125 0.625q-0.953125 0.78125 -0.953125 2.03125q0 1.125 0.765625 1.90625q0.75 0.765625 2.015625 0.84375zm5.765625 -9.141342l-9.671875 0l0 -1.46875l1.375 0q-1.59375 -1.0625 -1.59375 -3.078125q0 -0.875 0.3125 -1.609375q0.3125 -0.734375 0.828125 -1.09375q0.5 -0.375 1.203125 -0.515625q0.453125 -0.09375 1.59375 -0.09375l5.953125 0l0 1.640625l-5.890625 0q-1.0 0 -1.484375 0.203125q-0.5 0.1875 -0.796875 0.671875q-0.296875 0.484375 -0.296875 1.140625q0 1.046875 0.671875 1.8125q0.65625 0.75 2.515625 0.75l5.28125 0l0 1.640625zm-1.46875 -13.953842l1.453125 -0.234375q0.140625 0.6875 0.140625 1.234375q0 0.890625 -0.28125 1.390625q-0.28125 0.484375 -0.734375 0.6875q-0.46875 0.203125 -1.9375 0.203125l-5.578125 0l0 1.203125l-1.265625 0l0 -1.203125l-2.390625 0l-0.984375 -1.625l3.375 0l0 -1.65625l1.265625 0l0 1.65625l5.671875 0q0.6875 0 0.890625 -0.078125q0.203125 -0.09375 0.328125 -0.28125q0.109375 -0.203125 0.109375 -0.578125q0 -0.265625 -0.0625 -0.71875zm-10.0 -1.6051788l-1.890625 0l0 -1.640625l1.890625 0l0 1.640625zm11.46875 0l-9.671875 0l0 -1.640625l9.671875 0l0 1.640625zm-1.1875 -10.457321q0.765625 0.921875 1.09375 1.765625q0.3125 0.828125 0.3125 1.796875q0 1.59375 -0.78125 2.453125q-0.78125 0.859375 -1.984375 0.859375q-0.71875 0 -1.296875 -0.328125q-0.59375 -0.328125 -0.9375 -0.84375q-0.359375 -0.53125 -0.546875 -1.1875q-0.125 -0.46875 -0.25 -1.453125q-0.234375 -1.984375 -0.5625 -2.921875q-0.34375 -0.015625 -0.421875 -0.015625q-1.0 0 -1.421875 0.46875q-0.546875 0.625 -0.546875 1.875q0 1.15625 0.40625 1.703125q0.40625 0.546875 1.421875 0.8125l-0.21875 1.609375q-1.015625 -0.21875 -1.640625 -0.71875q-0.640625 -0.5 -0.984375 -1.453125q-0.34375 -0.953125 -0.34375 -2.1875q0 -1.25 0.296875 -2.015625q0.28125 -0.78125 0.734375 -1.140625q0.4375 -0.375 1.109375 -0.515625q0.421875 -0.078125 1.515625 -0.078125l2.1875 0q2.28125 0 2.890625 -0.109375q0.59375 -0.109375 1.15625 -0.40625l0 1.703125q-0.515625 0.265625 -1.1875 0.328125zm-3.671875 0.140625q0.375 0.890625 0.625 2.671875q0.140625 1.015625 0.328125 1.4375q0.1875 0.421875 0.53125 0.65625q0.34375 0.21875 0.78125 0.21875q0.65625 0 1.09375 -0.5q0.4375 -0.5 0.4375 -1.453125q0 -0.9375 -0.40625 -1.671875q-0.421875 -0.75 -1.140625 -1.09375q-0.5625 -0.265625 -1.640625 -0.265625l-0.609375 0zm4.859375 -4.156967l-13.359375 0l0 -1.640625l13.359375 0l0 1.640625zm0 -9.53125l-13.359375 0l0 -2.65625l9.453125 -3.15625q1.328125 -0.4375 1.984375 -0.640625q-0.734375 -0.234375 -2.140625 -0.703125l-9.296875 -3.203125l0 -2.375l13.359375 0l0 1.703125l-11.171875 0l11.171875 3.875l0 1.59375l-11.375 3.859375l11.375 0l0 1.703125zm-1.1875 -21.697052q0.765625 0.921875 1.09375 1.765625q0.3125 0.828125 0.3125 1.796875q0 1.59375 -0.78125 2.453125q-0.78125 0.859375 -1.984375 0.859375q-0.71875 0 -1.296875 -0.328125q-0.59375 -0.328125 -0.9375 -0.84375q-0.359375 -0.53125 -0.546875 -1.1875q-0.125 -0.46875 -0.25 -1.453125q-0.234375 -1.984375 -0.5625 -2.921875q-0.34375 -0.015625 -0.421875 -0.015625q-1.0 0 -1.421875 0.46875q-0.546875 0.625 -0.546875 1.875q0 1.15625 0.40625 1.703125q0.40625 0.546875 1.421875 0.8125l-0.21875 1.609375q-1.015625 -0.21875 -1.640625 -0.71875q-0.640625 -0.5 -0.984375 -1.453125q-0.34375 -0.953125 -0.34375 -2.1875q0 -1.25 0.296875 -2.015625q0.28125 -0.78125 0.734375 -1.140625q0.4375 -0.375 1.109375 -0.515625q0.421875 -0.078125 1.515625 -0.078125l2.1875 0q2.28125 0 2.890625 -0.109375q0.59375 -0.109375 1.15625 -0.40625l0 1.703125q-0.515625 0.265625 -1.1875 0.328125zm-3.671875 0.140625q0.375 0.890625 0.625 2.671875q0.140625 1.015625 0.328125 1.4375q0.1875 0.421875 0.53125 0.65625q0.34375 0.21875 0.78125 0.21875q0.65625 0 1.09375 -0.5q0.4375 -0.5 0.4375 -1.453125q0 -0.9375 -0.40625 -1.671875q-0.421875 -0.75 -1.140625 -1.09375q-0.5625 -0.265625 -1.640625 -0.265625l-0.609375 0zm4.859375 -4.203842l-9.671875 0l0 -1.46875l1.375 0q-1.59375 -1.0625 -1.59375 -3.078125q0 -0.875 0.3125 -1.609375q0.3125 -0.734375 0.828125 -1.09375q0.5 -0.375 1.203125 -0.515625q0.453125 -0.09375 1.59375 -0.09375l5.953125 0l0 1.640625l-5.890625 0q-1.0 0 -1.484375 0.203125q-0.5 0.1875 -0.796875 0.671875q-0.296875 0.484375 -0.296875 1.140625q0 1.046875 0.671875 1.8125q0.65625 0.75 2.515625 0.75l5.28125 0l0 1.640625zm-1.1875 -16.688217q0.765625 0.921875 1.09375 1.765625q0.3125 0.828125 0.3125 1.796875q0 1.59375 -0.78125 2.453125q-0.78125 0.859375 -1.984375 0.859375q-0.71875 0 -1.296875 -0.328125q-0.59375 -0.328125 -0.9375 -0.84375q-0.359375 -0.53125 -0.546875 -1.1875q-0.125 -0.46875 -0.25 -1.453125q-0.234375 -1.984375 -0.5625 -2.921875q-0.34375 -0.015625 -0.421875 -0.015625q-1.0 0 -1.421875 0.46875q-0.546875 0.625 -0.546875 1.875q0 1.15625 0.40625 1.703125q0.40625 0.546875 1.421875 0.8125l-0.21875 1.609375q-1.015625 -0.21875 -1.640625 -0.71875q-0.640625 -0.5 -0.984375 -1.453125q-0.34375 -0.953125 -0.34375 -2.1875q0 -1.25 0.296875 -2.015625q0.28125 -0.78125 0.734375 -1.140625q0.4375 -0.375 1.109375 -0.515625q0.421875 -0.078125 1.515625 -0.078125l2.1875 0q2.28125 0 2.890625 -0.109375q0.59375 -0.109375 1.15625 -0.40625l0 1.703125q-0.515625 0.265625 -1.1875 0.328125zm-3.671875 0.140625q0.375 0.890625 0.625 2.671875q0.140625 1.015625 0.328125 1.4375q0.1875 0.421875 0.53125 0.65625q0.34375 0.21875 0.78125 0.21875q0.65625 0 1.09375 -0.5q0.4375 -0.5 0.4375 -1.453125q0 -0.9375 -0.40625 -1.671875q-0.421875 -0.75 -1.140625 -1.09375q-0.5625 -0.265625 -1.640625 -0.265625l-0.609375 0zm5.65625 -3.8913422l0.234375 -1.59375q0.75 -0.109375 1.078125 -0.5625q0.453125 -0.609375 0.453125 -1.671875q0 -1.140625 -0.453125 -1.75q-0.453125 -0.625 -1.265625 -0.84375q-0.5 -0.125 -2.109375 -0.109375q1.265625 1.0625 1.265625 2.671875q0 2.0 -1.4375 3.09375q-1.4375 1.09375 -3.453125 1.09375q-1.390625 0 -2.5625 -0.5q-1.171875 -0.515625 -1.796875 -1.453125q-0.640625 -0.953125 -0.640625 -2.25q0 -1.703125 1.375 -2.8125l-1.15625 0l0 -1.515625l8.359375 0q2.265625 0 3.203125 0.46875q0.9375 0.453125 1.484375 1.453125q0.5468731 0.984375 0.5468731 2.453125q0 1.71875 -0.7812481 2.796875q-0.765625 1.0625 -2.34375 1.03125zm-5.8125 -1.359375q1.90625 0 2.78125 -0.75q0.875 -0.765625 0.875 -1.90625q0 -1.125 -0.859375 -1.890625q-0.875 -0.765625 -2.734375 -0.765625q-1.78125 0 -2.671875 0.796875q-0.90625 0.78125 -0.90625 1.890625q0 1.09375 0.890625 1.859375q0.875 0.765625 2.625 0.765625zm1.90625 -15.953842l0.203125 -1.6875q1.484375 0.40625 2.3125 1.484375q0.8125 1.078125 0.8125 2.765625q0 2.125 -1.296875 3.375q-1.3125 1.234375 -3.671875 1.234375q-2.453125 0 -3.796875 -1.25q-1.34375 -1.265625 -1.34375 -3.265625q0 -1.9375 1.328125 -3.15625q1.3125 -1.234375 3.703125 -1.234375q0.15625 0 0.4375 0l0 7.21875q1.59375 -0.09375 2.453125 -0.90625q0.84375 -0.8125 0.84375 -2.015625q0 -0.90625 -0.46875 -1.546875q-0.484375 -0.640625 -1.515625 -1.015625zm-2.65625 5.390625l0 -5.40625q-1.21875 0.109375 -1.828125 0.625q-0.953125 0.78125 -0.953125 2.03125q0 1.125 0.765625 1.90625q0.75 0.765625 2.015625 0.84375zm5.765625 -9.141342l-9.671875 0l0 -1.46875l1.359375 0q-0.71875 -0.453125 -1.140625 -1.203125q-0.4375 -0.765625 -0.4375 -1.71875q0 -1.078125 0.453125 -1.765625q0.4375 -0.6875 1.234375 -0.96875q-1.6875 -1.15625 -1.6875 -2.984375q0 -1.453125 0.796875 -2.21875q0.796875 -0.78125 2.453125 -0.78125l6.640625 0l0 1.640625l-6.09375 0q-0.984375 0 -1.40625 0.15625q-0.4375 0.15625 -0.703125 0.578125q-0.265625 0.421875 -0.265625 0.984375q0 1.015625 0.6875 1.6875q0.671875 0.671875 2.15625 0.671875l5.625 0l0 1.640625l-6.28125 0q-1.09375 0 -1.640625 0.40625q-0.546875 0.40625 -0.546875 1.3125q0 0.6875 0.359375 1.28125q0.359375 0.59375 1.0625 0.859375q0.703125 0.25 2.03125 0.25l5.015625 0l0 1.640625zm-3.109375 -22.165802l0.203125 -1.6875q1.484375 0.40625 2.3125 1.484375q0.8125 1.078125 0.8125 2.765625q0 2.125 -1.296875 3.375q-1.3125 1.234375 -3.671875 1.234375q-2.453125 0 -3.796875 -1.25q-1.34375 -1.265625 -1.34375 -3.265625q0 -1.9375 1.328125 -3.15625q1.3125 -1.234375 3.703125 -1.234375q0.15625 0 0.4375 0l0 7.21875q1.59375 -0.09375 2.453125 -0.90625q0.84375 -0.8125 0.84375 -2.015625q0 -0.90625 -0.46875 -1.546875q-0.484375 -0.640625 -1.515625 -1.015625zm-2.65625 5.390625l0 -5.40625q-1.21875 0.109375 -1.828125 0.625q-0.953125 0.78125 -0.953125 2.03125q0 1.125 0.765625 1.90625q0.75 0.765625 2.015625 0.84375zm5.765625 -9.141342l-9.671875 0l0 -1.46875l1.375 0q-1.59375 -1.0625 -1.59375 -3.078125q0 -0.875 0.3125 -1.609375q0.3125 -0.734375 0.828125 -1.09375q0.5 -0.375 1.203125 -0.515625q0.453125 -0.09375 1.59375 -0.09375l5.953125 0l0 1.640625l-5.890625 0q-1.0 0 -1.484375 0.203125q-0.5 0.1875 -0.796875 0.671875q-0.296875 0.484375 -0.296875 1.140625q0 1.046875 0.671875 1.8125q0.65625 0.75 2.515625 0.75l5.28125 0l0 1.640625zm-1.46875 -13.953842l1.453125 -0.234375q0.140625 0.6875 0.140625 1.234375q0 0.890625 -0.28125 1.390625q-0.28125 0.484375 -0.734375 0.6875q-0.46875 0.203125 -1.9375 0.203125l-5.578125 0l0 1.203125l-1.265625 0l0 -1.203125l-2.390625 0l-0.984375 -1.625l3.375 0l0 -1.65625l1.265625 0l0 1.65625l5.671875 0q0.6875 0 0.890625 -0.078125q0.203125 -0.09375 0.328125 -0.28125q0.109375 -0.203125 0.109375 -0.578125q0 -0.265625 -0.0625 -0.71875z" fill-rule="nonzero"/><path fill="#000000" fill-opacity="0.0" d="m43.66142 23.971128l47.937008 0" fill-rule="evenodd"/><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m43.66142 23.971128l41.937008 0" fill-rule="evenodd"/><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m85.59843 25.622862l4.5380936 -1.6517334l-4.5380936 -1.6517315z" fill-rule="evenodd"/><path fill="#cfe2f3" d="m91.59843 4.2860894l113.85827 0l0 39.370075l-113.85827 0z" fill-rule="evenodd"/><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m91.59843 4.2860894l113.85827 0l0 39.370075l-113.85827 0z" fill-rule="evenodd"/><path fill="#000000" d="m102.03593 30.891127l0 -13.359375l5.046875 0q1.328125 0 2.03125 0.125q0.96875 0.171875 1.640625 0.640625q0.671875 0.453125 1.078125 1.28125q0.40625 0.828125 0.40625 1.828125q0 1.703125 -1.09375 2.890625q-1.078125 1.171875 -3.921875 1.171875l-3.421875 0l0 5.421875l-1.765625 0zm1.765625 -7.0l3.453125 0q1.71875 0 2.4375 -0.640625q0.71875 -0.640625 0.71875 -1.796875q0 -0.84375 -0.421875 -1.4375q-0.421875 -0.59375 -1.125 -0.78125q-0.4375 -0.125 -1.640625 -0.125l-3.421875 0l0 4.78125zm16.787323 5.8125q-0.921875 0.765625 -1.765625 1.09375q-0.828125 0.3125 -1.796875 0.3125q-1.59375 0 -2.453125 -0.78125q-0.859375 -0.78125 -0.859375 -1.984375q0 -0.71875 0.328125 -1.296875q0.328125 -0.59375 0.84375 -0.9375q0.53125 -0.359375 1.1875 -0.546875q0.46875 -0.125 1.453125 -0.25q1.984375 -0.234375 2.921875 -0.5625q0.015625 -0.34375 0.015625 -0.421875q0 -1.0 -0.46875 -1.421875q-0.625 -0.546875 -1.875 -0.546875q-1.15625 0 -1.703125 0.40625q-0.546875 0.40625 -0.8125 1.421875l-1.609375 -0.21875q0.21875 -1.015625 0.71875 -1.640625q0.5 -0.640625 1.453125 -0.984375q0.953125 -0.34375 2.1875 -0.34375q1.25 0 2.015625 0.296875q0.78125 0.28125 1.140625 0.734375q0.375 0.4375 0.515625 1.109375q0.078125 0.421875 0.078125 1.515625l0 2.1875q0 2.28125 0.109375 2.890625q0.109375 0.59375 0.40625 1.15625l-1.703125 0q-0.265625 -0.515625 -0.328125 -1.1875zm-0.140625 -3.671875q-0.890625 0.375 -2.671875 0.625q-1.015625 0.140625 -1.4375 0.328125q-0.421875 0.1875 -0.65625 0.53125q-0.21875 0.34375 -0.21875 0.78125q0 0.65625 0.5 1.09375q0.5 0.4375 1.453125 0.4375q0.9375 0 1.671875 -0.40625q0.75 -0.421875 1.09375 -1.140625q0.265625 -0.5625 0.265625 -1.640625l0 -0.609375zm3.5475922 1.96875l1.625 -0.25q0.125 0.96875 0.75 1.5q0.625 0.515625 1.7499924 0.515625q1.125 0 1.671875 -0.453125q0.546875 -0.46875 0.546875 -1.09375q0 -0.546875 -0.484375 -0.875q-0.328125 -0.21875 -1.671875 -0.546875q-1.8124924 -0.46875 -2.5156174 -0.796875q-0.6875 -0.328125 -1.046875 -0.90625q-0.359375 -0.59375 -0.359375 -1.3125q0 -0.640625 0.296875 -1.1875q0.296875 -0.5625 0.8125 -0.921875q0.375 -0.28125 1.03125 -0.46875q0.671875 -0.203125 1.421875 -0.203125q1.1406174 0 1.9999924 0.328125q0.859375 0.328125 1.265625 0.890625q0.421875 0.5625 0.578125 1.5l-1.609375 0.21875q-0.109375 -0.75 -0.640625 -1.171875q-0.515625 -0.421875 -1.4687424 -0.421875q-1.140625 0 -1.625 0.375q-0.46875 0.375 -0.46875 0.875q0 0.3125 0.1875 0.578125q0.203125 0.265625 0.640625 0.4375q0.234375 0.09375 1.4374924 0.421875q1.75 0.453125 2.4375 0.75q0.6875 0.296875 1.078125 0.859375q0.390625 0.5625 0.390625 1.40625q0 0.828125 -0.484375 1.546875q-0.46875 0.71875 -1.375 1.125q-0.90625 0.390625 -2.046875 0.390625q-1.8749924 0 -2.8749924 -0.78125q-0.984375 -0.78125 -1.25 -2.328125zm9.328117 0l1.625 -0.25q0.125 0.96875 0.75 1.5q0.625 0.515625 1.75 0.515625q1.125 0 1.671875 -0.453125q0.546875 -0.46875 0.546875 -1.09375q0 -0.546875 -0.484375 -0.875q-0.328125 -0.21875 -1.671875 -0.546875q-1.8125 -0.46875 -2.515625 -0.796875q-0.6875 -0.328125 -1.046875 -0.90625q-0.359375 -0.59375 -0.359375 -1.3125q0 -0.640625 0.296875 -1.1875q0.296875 -0.5625 0.8125 -0.921875q0.375 -0.28125 1.03125 -0.46875q0.671875 -0.203125 1.421875 -0.203125q1.140625 0 2.0 0.328125q0.859375 0.328125 1.265625 0.890625q0.421875 0.5625 0.578125 1.5l-1.609375 0.21875q-0.109375 -0.75 -0.640625 -1.171875q-0.515625 -0.421875 -1.46875 -0.421875q-1.140625 0 -1.625 0.375q-0.46875 0.375 -0.46875 0.875q0 0.3125 0.1875 0.578125q0.203125 0.265625 0.640625 0.4375q0.234375 0.09375 1.4375 0.421875q1.75 0.453125 2.4375 0.75q0.6875 0.296875 1.078125 0.859375q0.390625 0.5625 0.390625 1.40625q0 0.828125 -0.484375 1.546875q-0.46875 0.71875 -1.375 1.125q-0.90625 0.390625 -2.046875 0.390625q-1.875 0 -2.875 -0.78125q-0.984375 -0.78125 -1.25 -2.328125zm11.765625 2.890625l-2.96875 -9.671875l1.703125 0l1.53125 5.578125l0.578125 2.078125q0.046875 -0.15625 0.5 -2.0l1.546875 -5.65625l1.6875 0l1.4375 5.609375l0.484375 1.84375l0.5625 -1.859375l1.65625 -5.59375l1.59375 0l-3.03125 9.671875l-1.703125 0l-1.53125 -5.796875l-0.375 -1.640625l-1.953125 7.4375l-1.71875 0zm11.082321 -4.84375q0 -2.6875 1.484375 -3.96875q1.25 -1.078125 3.046875 -1.078125q2.0 0 3.265625 1.3125q1.265625 1.296875 1.265625 3.609375q0 1.859375 -0.5625 2.9375q-0.5625 1.0625 -1.640625 1.65625q-1.0625 0.59375 -2.328125 0.59375q-2.03125 0 -3.28125 -1.296875q-1.25 -1.3125 -1.25 -3.765625zm1.6875 0q0 1.859375 0.796875 2.796875q0.8125 0.921875 2.046875 0.921875q1.21875 0 2.03125 -0.921875q0.8125 -0.9375 0.8125 -2.84375q0 -1.796875 -0.8125 -2.71875q-0.8125 -0.921875 -2.03125 -0.921875q-1.234375 0 -2.046875 0.921875q-0.796875 0.90625 -0.796875 2.765625zm9.281967 4.84375l0 -9.671875l1.46875 0l0 1.46875q0.5625 -1.03125 1.03125 -1.359375q0.484375 -0.328125 1.0625 -0.328125q0.828125 0 1.6875 0.53125l-0.5625 1.515625q-0.609375 -0.359375 -1.203125 -0.359375q-0.546875 0 -0.96875 0.328125q-0.421875 0.328125 -0.609375 0.890625q-0.28125 0.875 -0.28125 1.921875l0 5.0625l-1.625 0zm12.493927 0l0 -1.21875q-0.90625 1.4375 -2.703125 1.4375q-1.15625 0 -2.125 -0.640625q-0.96875 -0.640625 -1.5 -1.78125q-0.53125 -1.140625 -0.53125 -2.625q0 -1.453125 0.484375 -2.625q0.484375 -1.1875 1.4375 -1.8125q0.96875 -0.625 2.171875 -0.625q0.875 0 1.546875 0.375q0.6875 0.359375 1.109375 0.953125l0 -4.796875l1.640625 0l0 13.359375l-1.53125 0zm-5.171875 -4.828125q0 1.859375 0.78125 2.78125q0.78125 0.921875 1.84375 0.921875q1.078125 0 1.828125 -0.875q0.75 -0.890625 0.75 -2.6875q0 -1.984375 -0.765625 -2.90625q-0.765625 -0.9375 -1.890625 -0.9375q-1.078125 0 -1.8125 0.890625q-0.734375 0.890625 -0.734375 2.8125zm8.625717 1.9375l1.625 -0.25q0.125 0.96875 0.75 1.5q0.625 0.515625 1.75 0.515625q1.125 0 1.671875 -0.453125q0.546875 -0.46875 0.546875 -1.09375q0 -0.546875 -0.484375 -0.875q-0.328125 -0.21875 -1.671875 -0.546875q-1.8125 -0.46875 -2.515625 -0.796875q-0.6875 -0.328125 -1.046875 -0.90625q-0.359375 -0.59375 -0.359375 -1.3125q0 -0.640625 0.296875 -1.1875q0.296875 -0.5625 0.8125 -0.921875q0.375 -0.28125 1.03125 -0.46875q0.671875 -0.203125 1.421875 -0.203125q1.140625 0 2.0 0.328125q0.859375 0.328125 1.265625 0.890625q0.421875 0.5625 0.578125 1.5l-1.609375 0.21875q-0.109375 -0.75 -0.640625 -1.171875q-0.515625 -0.421875 -1.46875 -0.421875q-1.140625 0 -1.625 0.375q-0.46875 0.375 -0.46875 0.875q0 0.3125 0.1875 0.578125q0.203125 0.265625 0.640625 0.4375q0.234375 0.09375 1.4375 0.421875q1.75 0.453125 2.4375 0.75q0.6875 0.296875 1.078125 0.859375q0.390625 0.5625 0.390625 1.40625q0 0.828125 -0.484375 1.546875q-0.46875 0.71875 -1.375 1.125q-0.90625 0.390625 -2.046875 0.390625q-1.875 0 -2.875 -0.78125q-0.984375 -0.78125 -1.25 -2.328125z" fill-rule="nonzero"/><path fill="#cfe2f3" d="m91.59843 75.07874l113.85827 0l0 39.37008l-113.85827 0z" fill-rule="evenodd"/><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m91.59843 75.07874l113.85827 0l0 39.37008l-113.85827 0z" fill-rule="evenodd"/><path fill="#000000" d="m104.36405 101.68378l-3.53125 -13.359375l1.8125 0l2.03125 8.765625q0.328125 1.375 0.5625 2.71875q0.5 -2.140625 0.59375 -2.46875l2.546875 -9.015625l2.125 0l1.921875 6.765625q0.71875 2.515625 1.03125 4.71875q0.265625 -1.265625 0.671875 -2.890625l2.09375 -8.59375l1.78125 0l-3.671875 13.359375l-1.703125 0l-2.8125 -10.171875q-0.359375 -1.28125 -0.421875 -1.5625q-0.203125 0.90625 -0.390625 1.5625l-2.828125 10.171875l-1.8125 0zm21.365173 -3.109375l1.6875 0.203125q-0.40625 1.484375 -1.484375 2.3125q-1.078125 0.8125 -2.765625 0.8125q-2.125 0 -3.375 -1.296875q-1.234375 -1.3125 -1.234375 -3.671875q0 -2.453125 1.25 -3.796875q1.265625 -1.34375 3.265625 -1.34375q1.9375 0 3.15625 1.328125q1.234375 1.3125 1.234375 3.703125q0 0.15625 0 0.4375l-7.21875 0q0.09375 1.59375 0.90625 2.453125q0.8125 0.84375 2.015625 0.84375q0.90625 0 1.546875 -0.46875q0.640625 -0.484375 1.015625 -1.515625zm-5.390625 -2.65625l5.40625 0q-0.109375 -1.21875 -0.625 -1.828125q-0.78125 -0.953125 -2.03125 -0.953125q-1.125 0 -1.90625 0.765625q-0.765625 0.75 -0.84375 2.015625zm10.641335 5.765625l-1.515625 0l0 -13.359375l1.640625 0l0 4.765625q1.046875 -1.296875 2.65625 -1.296875q0.890625 0 1.6875 0.359375q0.796875 0.359375 1.3125 1.015625q0.515625 0.640625 0.796875 1.5625q0.296875 0.921875 0.296875 1.96875q0 2.484375 -1.234375 3.84375q-1.21875 1.359375 -2.953125 1.359375q-1.703125 0 -2.6875 -1.4375l0 1.21875zm-0.015625 -4.90625q0 1.734375 0.484375 2.515625q0.765625 1.265625 2.09375 1.265625q1.078125 0 1.859375 -0.9375q0.78125 -0.9375 0.78125 -2.78125q0 -1.890625 -0.75 -2.796875q-0.75 -0.90625 -1.828125 -0.90625q-1.0625 0 -1.859375 0.9375q-0.78125 0.9375 -0.78125 2.703125zm7.625717 4.90625l5.125 -13.359375l1.90625 0l5.46875 13.359375l-2.015625 0l-1.546875 -4.046875l-5.59375 0l-1.46875 4.046875l-1.875 0zm3.859375 -5.484375l4.53125 0l-1.40625 -3.703125q-0.625 -1.6875 -0.9375 -2.765625q-0.265625 1.28125 -0.71875 2.546875l-1.46875 3.921875zm16.177948 5.484375l0 -1.421875q-1.125 1.640625 -3.0625 1.640625q-0.859375 0 -1.609375 -0.328125q-0.734375 -0.328125 -1.09375 -0.828125q-0.359375 -0.5 -0.5 -1.21875q-0.109375 -0.46875 -0.109375 -1.53125l0 -5.984375l1.640625 0l0 5.359375q0 1.28125 0.109375 1.734375q0.15625 0.640625 0.65625 1.015625q0.5 0.375 1.234375 0.375q0.734375 0 1.375 -0.375q0.65625 -0.390625 0.921875 -1.03125q0.265625 -0.65625 0.265625 -1.890625l0 -5.1875l1.640625 0l0 9.671875l-1.46875 0zm7.625717 -1.46875l0.234375 1.453125q-0.6875 0.140625 -1.234375 0.140625q-0.890625 0 -1.390625 -0.28125q-0.484375 -0.28125 -0.6875 -0.734375q-0.203125 -0.46875 -0.203125 -1.9375l0 -5.578125l-1.203125 0l0 -1.265625l1.203125 0l0 -2.390625l1.625 -0.984375l0 3.375l1.65625 0l0 1.265625l-1.65625 0l0 5.671875q0 0.6875 0.078125 0.890625q0.09375 0.203125 0.28125 0.328125q0.203125 0.109375 0.578125 0.109375q0.265625 0 0.71875 -0.0625zm1.6051788 1.46875l0 -13.359375l1.640625 0l0 4.796875q1.140625 -1.328125 2.890625 -1.328125q1.078125 0 1.859375 0.421875q0.796875 0.421875 1.140625 1.171875q0.34375 0.75 0.34375 2.171875l0 6.125l-1.640625 0l0 -6.125q0 -1.234375 -0.53125 -1.796875q-0.53125 -0.5625 -1.515625 -0.5625q-0.71875 0 -1.359375 0.390625q-0.640625 0.375 -0.921875 1.015625q-0.265625 0.640625 -0.265625 1.78125l0 5.296875l-1.640625 0zm10.375717 0l0 -9.671875l1.46875 0l0 1.375q1.0625 -1.59375 3.078125 -1.59375q0.875 0 1.609375 0.3125q0.734375 0.3125 1.09375 0.828125q0.375 0.5 0.515625 1.203125q0.09375 0.453125 0.09375 1.59375l0 5.953125l-1.640625 0l0 -5.890625q0 -1.0 -0.203125 -1.484375q-0.1875 -0.5 -0.671875 -0.796875q-0.484375 -0.296875 -1.140625 -0.296875q-1.046875 0 -1.8125 0.671875q-0.75 0.65625 -0.75 2.515625l0 5.28125l-1.640625 0z" fill-rule="nonzero"/><path fill="#cfe2f3" d="m91.59843 314.5328l0 -168.66142l39.37008 0l0 168.66142z" fill-rule="evenodd"/><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m91.59843 314.5328l0 -168.66142l39.37008 0l0 168.66142z" fill-rule="evenodd"/><path fill="#000000" d="m118.20346 303.79843l-13.359375 0l0 -1.765625l13.359375 0l0 1.765625zm0 -10.948914l-1.21875 0q1.4375 0.90625 1.4375 2.703125q0 1.15625 -0.640625 2.125q-0.640625 0.96875 -1.78125 1.5q-1.140625 0.53125 -2.625 0.53125q-1.453125 0 -2.625 -0.484375q-1.1875 -0.484375 -1.8125 -1.4375q-0.625 -0.96875 -0.625 -2.171875q0 -0.875 0.375 -1.546875q0.359375 -0.6875 0.953125 -1.109375l-4.796875 0l0 -1.640625l13.359375 0l0 1.53125zm-4.828125 5.171875q1.859375 0 2.78125 -0.78125q0.921875 -0.78125 0.921875 -1.84375q0 -1.078125 -0.875 -1.828125q-0.890625 -0.75 -2.6875 -0.75q-1.984375 0 -2.90625 0.765625q-0.9375 0.765625 -0.9375 1.890625q0 1.078125 0.890625 1.8125q0.890625 0.734375 2.8125 0.734375zm1.71875 -15.906982l0.203125 -1.6875q1.484375 0.40625 2.3125 1.484375q0.8125 1.078125 0.8125 2.765625q0 2.125 -1.296875 3.375q-1.3125 1.234375 -3.671875 1.234375q-2.453125 0 -3.796875 -1.25q-1.34375 -1.265625 -1.34375 -3.265625q0 -1.9375 1.328125 -3.15625q1.3125 -1.234375 3.703125 -1.234375q0.15625 0 0.4375 0l0 7.21875q1.59375 -0.09375 2.453125 -0.90625q0.84375 -0.8125 0.84375 -2.015625q0 -0.90625 -0.46875 -1.546875q-0.484375 -0.640625 -1.515625 -1.015625zm-2.65625 5.390625l0 -5.40625q-1.21875 0.109375 -1.828125 0.625q-0.953125 0.78125 -0.953125 2.03125q0 1.125 0.765625 1.90625q0.75 0.765625 2.015625 0.84375zm5.765625 -9.141327l-9.671875 0l0 -1.46875l1.375 0q-1.59375 -1.0625 -1.59375 -3.078125q0 -0.875 0.3125 -1.609375q0.3125 -0.734375 0.828125 -1.09375q0.5 -0.375 1.203125 -0.515625q0.453125 -0.09375 1.59375 -0.09375l5.953125 0l0 1.640625l-5.890625 0q-1.0 0 -1.484375 0.203125q-0.5 0.1875 -0.796875 0.671875q-0.296875 0.484375 -0.296875 1.140625q0 1.046875 0.671875 1.8125q0.65625 0.75 2.515625 0.75l5.28125 0l0 1.640625zm-1.46875 -13.953857l1.453125 -0.234375q0.140625 0.6875 0.140625 1.234375q0 0.890625 -0.28125 1.390625q-0.28125 0.484375 -0.734375 0.6875q-0.46875 0.203125 -1.9375 0.203125l-5.578125 0l0 1.203125l-1.265625 0l0 -1.203125l-2.390625 0l-0.984375 -1.625l3.375 0l0 -1.65625l1.265625 0l0 1.65625l5.671875 0q0.6875 0 0.890625 -0.078125q0.203125 -0.09375 0.328125 -0.28125q0.109375 -0.203125 0.109375 -0.578125q0 -0.265625 -0.0625 -0.71875zm-10.0 -1.6051636l-1.890625 0l0 -1.640625l1.890625 0l0 1.640625zm11.46875 0l-9.671875 0l0 -1.640625l9.671875 0l0 1.640625zm-1.46875 -7.7229614l1.453125 -0.234375q0.140625 0.6875 0.140625 1.234375q0 0.890625 -0.28125 1.390625q-0.28125 0.484375 -0.734375 0.6875q-0.46875 0.203125 -1.9375 0.203125l-5.578125 0l0 1.203125l-1.265625 0l0 -1.203125l-2.390625 0l-0.984375 -1.625l3.375 0l0 -1.65625l1.265625 0l0 1.65625l5.671875 0q0.6875 0 0.890625 -0.078125q0.203125 -0.09375 0.328125 -0.28125q0.109375 -0.203125 0.109375 -0.578125q0 -0.265625 -0.0625 -0.71875zm5.1875 -1.5270538l-1.53125 0.1875q0.140625 -0.546875 0.140625 -0.9375q0 -0.546875 -0.1875 -0.875q-0.171875 -0.328125 -0.5 -0.546875q-0.25 -0.15625 -1.21875 -0.5q-0.140625 -0.046875 -0.40625 -0.140625l-9.6875 3.671875l0 -1.765625l5.59375 -2.015625q1.078125 -0.390625 2.25 -0.703125q-1.125 -0.28125 -2.203125 -0.671875l-5.640625 -2.078125l0 -1.640625l9.828125 3.6875q1.609375 0.59375 2.203125 0.921875q0.8125 0.4375 1.1875 1.0q0.375 0.5625 0.375 1.34375q0 0.484375 -0.203125 1.0625zm-8.40625 -19.140625l0.453125 -1.765625q2.171875 0.5625 3.328125 2.0q1.140625 1.4375 1.140625 3.53125q0 2.15625 -0.875 3.515625q-0.890625 1.34375 -2.546875 2.0625q-1.671875 0.703125 -3.59375 0.703125q-2.078125 0 -3.625 -0.796875q-1.5625 -0.796875 -2.359375 -2.265625q-0.8125 -1.484375 -0.8125 -3.25q0 -2.0 1.015625 -3.359375q1.015625 -1.375 2.875 -1.90625l0.40625 1.734375q-1.453125 0.46875 -2.109375 1.359375q-0.671875 0.875 -0.671875 2.203125q0 1.546875 0.734375 2.578125q0.734375 1.03125 1.984375 1.453125q1.234375 0.421875 2.5625 0.421875q1.703125 0 2.96875 -0.5q1.265625 -0.5 1.90625 -1.546875q0.625 -1.046875 0.625 -2.265625q0 -1.484375 -0.859375 -2.515625q-0.859375 -1.03125 -2.546875 -1.390625zm4.6875 -3.7229462l-9.671875 0l0 -1.46875l1.46875 0q-1.03125 -0.5625 -1.359375 -1.03125q-0.328125 -0.484375 -0.328125 -1.0625q0 -0.828125 0.53125 -1.6875l1.515625 0.5625q-0.359375 0.609375 -0.359375 1.203125q0 0.546875 0.328125 0.96875q0.328125 0.421875 0.890625 0.609375q0.875 0.28125 1.921875 0.28125l5.0625 0l0 1.625zm-3.109375 -12.853302l0.203125 -1.6875q1.484375 0.40625 2.3125 1.484375q0.8125 1.078125 0.8125 2.765625q0 2.125 -1.296875 3.375q-1.3125 1.234375 -3.671875 1.234375q-2.453125 0 -3.796875 -1.25q-1.34375 -1.265625 -1.34375 -3.265625q0 -1.9375 1.328125 -3.15625q1.3125 -1.234375 3.703125 -1.234375q0.15625 0 0.4375 0l0 7.21875q1.59375 -0.09375 2.453125 -0.90625q0.84375 -0.8125 0.84375 -2.015625q0 -0.90625 -0.46875 -1.546875q-0.484375 -0.640625 -1.515625 -1.015625zm-2.65625 5.390625l0 -5.40625q-1.21875 0.109375 -1.828125 0.625q-0.953125 0.78125 -0.953125 2.03125q0 1.125 0.765625 1.90625q0.75 0.765625 2.015625 0.84375zm5.765625 -15.406967l-1.21875 0q1.4375 0.90625 1.4375 2.703125q0 1.15625 -0.640625 2.125q-0.640625 0.96875 -1.78125 1.5q-1.140625 0.53125 -2.625 0.53125q-1.453125 0 -2.625 -0.484375q-1.1875 -0.484375 -1.8125 -1.4375q-0.625 -0.96875 -0.625 -2.171875q0 -0.875 0.375 -1.546875q0.359375 -0.6875 0.953125 -1.109375l-4.796875 0l0 -1.640625l13.359375 0l0 1.53125zm-4.828125 5.171875q1.859375 0 2.78125 -0.78125q0.921875 -0.78125 0.921875 -1.84375q0 -1.078125 -0.875 -1.828125q-0.890625 -0.75 -2.6875 -0.75q-1.984375 0 -2.90625 0.765625q-0.9375 0.765625 -0.9375 1.890625q0 1.078125 0.890625 1.8125q0.890625 0.734375 2.8125 0.734375zm1.71875 -15.906967l0.203125 -1.6875q1.484375 0.40625 2.3125 1.484375q0.8125 1.078125 0.8125 2.765625q0 2.125 -1.296875 3.375q-1.3125 1.234375 -3.671875 1.234375q-2.453125 0 -3.796875 -1.25q-1.34375 -1.265625 -1.34375 -3.265625q0 -1.9375 1.328125 -3.15625q1.3125 -1.234375 3.703125 -1.234375q0.15625 0 0.4375 0l0 7.21875q1.59375 -0.09375 2.453125 -0.90625q0.84375 -0.8125 0.84375 -2.015625q0 -0.90625 -0.46875 -1.546875q-0.484375 -0.640625 -1.515625 -1.015625zm-2.65625 5.390625l0 -5.40625q-1.21875 0.109375 -1.828125 0.625q-0.953125 0.78125 -0.953125 2.03125q0 1.125 0.765625 1.90625q0.75 0.765625 2.015625 0.84375zm5.765625 -9.141342l-9.671875 0l0 -1.46875l1.375 0q-1.59375 -1.0625 -1.59375 -3.078125q0 -0.875 0.3125 -1.609375q0.3125 -0.734375 0.828125 -1.09375q0.5 -0.375 1.203125 -0.515625q0.453125 -0.09375 1.59375 -0.09375l5.953125 0l0 1.640625l-5.890625 0q-1.0 0 -1.484375 0.203125q-0.5 0.1875 -0.796875 0.671875q-0.296875 0.484375 -0.296875 1.140625q0 1.046875 0.671875 1.8125q0.65625 0.75 2.515625 0.75l5.28125 0l0 1.640625zm-1.46875 -13.953842l1.453125 -0.234375q0.140625 0.6875 0.140625 1.234375q0 0.890625 -0.28125 1.390625q-0.28125 0.484375 -0.734375 0.6875q-0.46875 0.203125 -1.9375 0.203125l-5.578125 0l0 1.203125l-1.265625 0l0 -1.203125l-2.390625 0l-0.984375 -1.625l3.375 0l0 -1.65625l1.265625 0l0 1.65625l5.671875 0q0.6875 0 0.890625 -0.078125q0.203125 -0.09375 0.328125 -0.28125q0.109375 -0.203125 0.109375 -0.578125q0 -0.265625 -0.0625 -0.71875zm-10.0 -1.6051788l-1.890625 0l0 -1.640625l1.890625 0l0 1.640625zm11.46875 0l-9.671875 0l0 -1.640625l9.671875 0l0 1.640625zm-1.1875 -10.457321q0.765625 0.921875 1.09375 1.765625q0.3125 0.828125 0.3125 1.796875q0 1.59375 -0.78125 2.453125q-0.78125 0.859375 -1.984375 0.859375q-0.71875 0 -1.296875 -0.328125q-0.59375 -0.328125 -0.9375 -0.84375q-0.359375 -0.53125 -0.546875 -1.1875q-0.125 -0.46875 -0.25 -1.453125q-0.234375 -1.984375 -0.5625 -2.921875q-0.34375 -0.015625 -0.421875 -0.015625q-1.0 0 -1.421875 0.46875q-0.546875 0.625 -0.546875 1.875q0 1.15625 0.40625 1.703125q0.40625 0.546875 1.421875 0.8125l-0.21875 1.609375q-1.015625 -0.21875 -1.640625 -0.71875q-0.640625 -0.5 -0.984375 -1.453125q-0.34375 -0.953125 -0.34375 -2.1875q0 -1.25 0.296875 -2.015625q0.28125 -0.78125 0.734375 -1.140625q0.4375 -0.375 1.109375 -0.515625q0.421875 -0.078125 1.515625 -0.078125l2.1875 0q2.28125 0 2.890625 -0.109375q0.59375 -0.109375 1.15625 -0.40625l0 1.703125q-0.515625 0.265625 -1.1875 0.328125zm-3.671875 0.140625q0.375 0.890625 0.625 2.671875q0.140625 1.015625 0.328125 1.4375q0.1875 0.421875 0.53125 0.65625q0.34375 0.21875 0.78125 0.21875q0.65625 0 1.09375 -0.5q0.4375 -0.5 0.4375 -1.453125q0 -0.9375 -0.40625 -1.671875q-0.421875 -0.75 -1.140625 -1.09375q-0.5625 -0.265625 -1.640625 -0.265625l-0.609375 0zm4.859375 -4.156967l-13.359375 0l0 -1.640625l13.359375 0l0 1.640625z" fill-rule="nonzero"/><path fill="#000000" fill-opacity="0.0" d="m43.66142 94.76378l47.937008 0" fill-rule="evenodd"/><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m43.66142 94.76378l41.937008 0" fill-rule="evenodd"/><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m85.59843 96.41551l4.5380936 -1.6517334l-4.5380936 -1.6517334z" fill-rule="evenodd"/><path fill="#000000" fill-opacity="0.0" d="m43.66142 165.55643l47.937008 0" fill-rule="evenodd"/><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m43.66142 165.55643l41.937008 0" fill-rule="evenodd"/><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m85.59843 167.20816l4.5380936 -1.6517334l-4.5380936 -1.6517334z" fill-rule="evenodd"/><path fill="#000000" fill-opacity="0.0" d="m130.9685 165.55643l47.93701 0" fill-rule="evenodd"/><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m130.9685 165.55643l41.93701 0" fill-rule="evenodd"/><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m172.90552 167.20816l4.538086 -1.6517334l-4.538086 -1.6517334z" fill-rule="evenodd"/><path fill="#cfe2f3" d="m179.76378 145.87138l113.85826 0l0 39.370087l-113.85826 0z" fill-rule="evenodd"/><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m179.76378 145.87138l113.85826 0l0 39.370087l-113.85826 0z" fill-rule="evenodd"/><path fill="#000000" d="m189.99815 172.47643l0 -9.671875l1.46875 0l0 1.359375q0.453125 -0.71875 1.203125 -1.140625q0.765625 -0.4375 1.71875 -0.4375q1.078125 0 1.765625 0.453125q0.6875 0.4375 0.96875 1.234375q1.15625 -1.6875 2.984375 -1.6875q1.453125 0 2.21875 0.796875q0.78125 0.796875 0.78125 2.453125l0 6.640625l-1.640625 0l0 -6.09375q0 -0.984375 -0.15625 -1.40625q-0.15625 -0.4375 -0.578125 -0.703125q-0.421875 -0.265625 -0.984375 -0.265625q-1.015625 0 -1.6875 0.6875q-0.671875 0.671875 -0.671875 2.15625l0 5.625l-1.640625 0l0 -6.28125q0 -1.09375 -0.40625 -1.640625q-0.40625 -0.546875 -1.3125 -0.546875q-0.6875 0 -1.28125 0.359375q-0.59375 0.359375 -0.859375 1.0625q-0.25 0.703125 -0.25 2.03125l0 5.015625l-1.640625 0zm21.806427 0l0 -1.21875q-0.90625 1.4375 -2.703125 1.4375q-1.15625 0 -2.125 -0.640625q-0.96875 -0.640625 -1.5 -1.78125q-0.53125 -1.140625 -0.53125 -2.625q0 -1.453125 0.484375 -2.625q0.484375 -1.1875 1.4375 -1.8125q0.96875 -0.625 2.171875 -0.625q0.875 0 1.546875 0.375q0.6875 0.359375 1.109375 0.953125l0 -4.796875l1.640625 0l0 13.359375l-1.53125 0zm-5.171875 -4.828125q0 1.859375 0.78125 2.78125q0.78125 0.921875 1.84375 0.921875q1.078125 0 1.828125 -0.875q0.75 -0.890625 0.75 -2.6875q0 -1.984375 -0.765625 -2.90625q-0.765625 -0.9375 -1.890625 -0.9375q-1.078125 0 -1.8125 0.890625q-0.734375 0.890625 -0.734375 2.8125zm8.672592 -0.015625q0 -2.6875 1.484375 -3.96875q1.25 -1.078125 3.046875 -1.078125q2.0 0 3.265625 1.3125q1.265625 1.296875 1.265625 3.609375q0 1.859375 -0.5625 2.9375q-0.5625 1.0625 -1.640625 1.65625q-1.0625 0.59375 -2.328125 0.59375q-2.03125 0 -3.28125 -1.296875q-1.25 -1.3125 -1.25 -3.765625zm1.6875 0q0 1.859375 0.796875 2.796875q0.8125 0.921875 2.046875 0.921875q1.21875 0 2.03125 -0.921875q0.8125 -0.9375 0.8125 -2.84375q0 -1.796875 -0.8125 -2.71875q-0.8125 -0.921875 -2.03125 -0.921875q-1.234375 0 -2.046875 0.921875q-0.796875 0.90625 -0.796875 2.765625zm15.610092 1.296875l1.609375 0.21875q-0.265625 1.65625 -1.359375 2.609375q-1.078125 0.9375 -2.671875 0.9375q-1.984375 0 -3.1875 -1.296875q-1.203125 -1.296875 -1.203125 -3.71875q0 -1.578125 0.515625 -2.75q0.515625 -1.171875 1.578125 -1.75q1.0625 -0.59375 2.3125 -0.59375q1.578125 0 2.578125 0.796875q1.0 0.796875 1.28125 2.265625l-1.59375 0.234375q-0.234375 -0.96875 -0.8125 -1.453125q-0.578125 -0.5 -1.390625 -0.5q-1.234375 0 -2.015625 0.890625q-0.78125 0.890625 -0.78125 2.8125q0 1.953125 0.75 2.84375q0.75 0.875 1.953125 0.875q0.96875 0 1.609375 -0.59375q0.65625 -0.59375 0.828125 -1.828125z" fill-rule="nonzero"/><path fill="#cfe2f3" d="m179.76378 210.47397l113.85826 0l0 39.37007l-113.85826 0z" fill-rule="evenodd"/><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m179.76378 210.47397l113.85826 0l0 39.37007l-113.85826 0z" fill-rule="evenodd"/><path fill="#000000" d="m190.29503 237.07901l0 -13.359375l9.015625 0l0 1.578125l-7.25 0l0 4.140625l6.265625 0l0 1.578125l-6.265625 0l0 6.0625l-1.765625 0zm17.724106 -3.109375l1.6875 0.203125q-0.40625 1.484375 -1.484375 2.3125q-1.078125 0.8125 -2.765625 0.8125q-2.125 0 -3.375 -1.296875q-1.234375 -1.3125 -1.234375 -3.671875q0 -2.453125 1.25 -3.796875q1.265625 -1.34375 3.265625 -1.34375q1.9375 0 3.15625 1.328125q1.234375 1.3125 1.234375 3.703125q0 0.15625 0 0.4375l-7.21875 0q0.09375 1.59375 0.90625 2.453125q0.8125 0.84375 2.015625 0.84375q0.90625 0 1.546875 -0.46875q0.640625 -0.484375 1.015625 -1.515625zm-5.390625 -2.65625l5.40625 0q-0.109375 -1.21875 -0.625 -1.828125q-0.78125 -0.953125 -2.03125 -0.953125q-1.125 0 -1.90625 0.765625q-0.765625 0.75 -0.84375 2.015625zm15.406967 5.765625l0 -1.21875q-0.90625 1.4375 -2.703125 1.4375q-1.15625 0 -2.125 -0.640625q-0.96875 -0.640625 -1.5 -1.78125q-0.53125 -1.140625 -0.53125 -2.625q0 -1.453125 0.484375 -2.625q0.484375 -1.1875 1.4375 -1.8125q0.96875 -0.625 2.171875 -0.625q0.875 0 1.546875 0.375q0.6875 0.359375 1.109375 0.953125l0 -4.796875l1.640625 0l0 13.359375l-1.53125 0zm-5.171875 -4.828125q0 1.859375 0.78125 2.78125q0.78125 0.921875 1.84375 0.921875q1.078125 0 1.828125 -0.875q0.75 -0.890625 0.75 -2.6875q0 -1.984375 -0.765625 -2.90625q-0.765625 -0.9375 -1.890625 -0.9375q-1.078125 0 -1.8125 0.890625q-0.734375 0.890625 -0.734375 2.8125zm19.016342 0.140625l1.765625 0.453125q-0.5625 2.171875 -2.0 3.328125q-1.4375 1.140625 -3.53125 1.140625q-2.15625 0 -3.515625 -0.875q-1.34375 -0.890625 -2.0625 -2.546875q-0.703125 -1.671875 -0.703125 -3.59375q0 -2.078125 0.796875 -3.625q0.796875 -1.5625 2.265625 -2.359375q1.484375 -0.8125 3.25 -0.8125q2.0 0 3.359375 1.015625q1.375 1.015625 1.90625 2.875l-1.734375 0.40625q-0.46875 -1.453125 -1.359375 -2.109375q-0.875 -0.671875 -2.203125 -0.671875q-1.546875 0 -2.578125 0.734375q-1.03125 0.734375 -1.453125 1.984375q-0.421875 1.234375 -0.421875 2.5625q0 1.703125 0.5 2.96875q0.5 1.265625 1.546875 1.90625q1.046875 0.625 2.265625 0.625q1.484375 0 2.515625 -0.859375q1.03125 -0.859375 1.390625 -2.546875zm3.8948212 4.6875l0 -13.359375l2.65625 0l3.15625 9.453125q0.4375 1.328125 0.640625 1.984375q0.234375 -0.734375 0.703125 -2.140625l3.203125 -9.296875l2.375 0l0 13.359375l-1.703125 0l0 -11.171875l-3.875 11.171875l-1.59375 0l-3.859375 -11.375l0 11.375l-1.703125 0z" fill-rule="nonzero"/><path fill="#000000" fill-opacity="0.0" d="m130.9685 230.15901l47.93701 0" fill-rule="evenodd"/><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m130.9685 230.159l41.93701 0" fill-rule="evenodd"/><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m172.90552 231.81073l4.538086 -1.6517334l-4.538086 -1.6517334z" fill-rule="evenodd"/><path fill="#000000" fill-opacity="0.0" d="m130.9685 294.27823l47.93701 0" fill-rule="evenodd"/><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m130.9685 294.27823l41.93701 0" fill-rule="evenodd"/><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m172.90552 295.92996l4.538086 -1.6517334l-4.538086 -1.6517334z" fill-rule="evenodd"/><path fill="#cfe2f3" d="m179.76378 274.59317l113.85826 0l0 39.370087l-113.85826 0z" fill-rule="evenodd"/><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m179.76378 274.59317l113.85826 0l0 39.370087l-113.85826 0z" fill-rule="evenodd"/><path fill="#000000" d="m192.5294 301.1982l-3.53125 -13.359375l1.8125 0l2.03125 8.765625q0.328125 1.375 0.5625 2.71875q0.5 -2.140625 0.59375 -2.46875l2.546875 -9.015625l2.125 0l1.921875 6.765625q0.71875 2.515625 1.03125 4.71875q0.265625 -1.265625 0.671875 -2.890625l2.09375 -8.59375l1.78125 0l-3.671875 13.359375l-1.703125 0l-2.8125 -10.171875q-0.359375 -1.28125 -0.421875 -1.5625q-0.203125 0.90625 -0.390625 1.5625l-2.828125 10.171875l-1.8125 0zm14.624283 -3.53125l1.640625 -0.21875q0.28125 1.40625 0.953125 2.015625q0.6875 0.609375 1.65625 0.609375q1.15625 0 1.953125 -0.796875q0.796875 -0.796875 0.796875 -1.984375q0 -1.125 -0.734375 -1.859375q-0.734375 -0.734375 -1.875 -0.734375q-0.46875 0 -1.15625 0.171875l0.1875 -1.4375q0.15625 0.015625 0.265625 0.015625q1.046875 0 1.875 -0.546875q0.84375 -0.546875 0.84375 -1.671875q0 -0.90625 -0.609375 -1.5q-0.609375 -0.59375 -1.578125 -0.59375q-0.953125 0 -1.59375 0.609375q-0.640625 0.59375 -0.8125 1.796875l-1.640625 -0.296875q0.296875 -1.640625 1.359375 -2.546875q1.0625 -0.90625 2.65625 -0.90625q1.09375 0 2.0 0.46875q0.921875 0.46875 1.40625 1.28125q0.5 0.8125 0.5 1.71875q0 0.859375 -0.46875 1.578125q-0.46875 0.703125 -1.375 1.125q1.1875 0.28125 1.84375 1.140625q0.65625 0.859375 0.65625 2.15625q0 1.734375 -1.28125 2.953125q-1.265625 1.21875 -3.21875 1.21875q-1.765625 0 -2.921875 -1.046875q-1.15625 -1.046875 -1.328125 -2.71875zm20.563217 -1.15625l1.765625 0.453125q-0.5625 2.171875 -2.0 3.328125q-1.4375 1.140625 -3.53125 1.140625q-2.15625 0 -3.515625 -0.875q-1.34375 -0.890625 -2.0625 -2.546875q-0.703125 -1.671875 -0.703125 -3.59375q0 -2.078125 0.796875 -3.625q0.796875 -1.5625 2.265625 -2.359375q1.484375 -0.8125 3.25 -0.8125q2.0 0 3.359375 1.015625q1.375 1.015625 1.90625 2.875l-1.734375 0.40625q-0.46875 -1.453125 -1.359375 -2.109375q-0.875 -0.671875 -2.203125 -0.671875q-1.546875 0 -2.578125 0.734375q-1.03125 0.734375 -1.453125 1.984375q-0.421875 1.234375 -0.421875 2.5625q0 1.703125 0.5 2.96875q0.5 1.265625 1.546875 1.90625q1.046875 0.625 2.265625 0.625q1.484375 0 2.515625 -0.859375q1.03125 -0.859375 1.390625 -2.546875zm12.9375 4.6875l-5.171875 -13.359375l1.921875 0l3.46875 9.703125q0.421875 1.171875 0.703125 2.1875q0.3125 -1.09375 0.71875 -2.1875l3.609375 -9.703125l1.796875 0l-5.234375 13.359375l-1.8125 0zm18.162338 -4.6875l1.765625 0.453125q-0.5625 2.171875 -2.0 3.328125q-1.4375 1.140625 -3.5312653 1.140625q-2.15625 0 -3.515625 -0.875q-1.34375 -0.890625 -2.0625 -2.546875q-0.703125 -1.671875 -0.703125 -3.59375q0 -2.078125 0.796875 -3.625q0.796875 -1.5625 2.265625 -2.359375q1.484375 -0.8125 3.25 -0.8125q2.0000153 0 3.3593903 1.015625q1.375 1.015625 1.90625 2.875l-1.734375 0.40625q-0.46875 -1.453125 -1.359375 -2.109375q-0.875 -0.671875 -2.2031403 -0.671875q-1.546875 0 -2.578125 0.734375q-1.03125 0.734375 -1.453125 1.984375q-0.421875 1.234375 -0.421875 2.5625q0 1.703125 0.5 2.96875q0.5 1.265625 1.546875 1.90625q1.046875 0.625 2.265625 0.625q1.4843903 0 2.5156403 -0.859375q1.03125 -0.859375 1.390625 -2.546875z" fill-rule="nonzero"/></g></svg>


--------------------------------------------------------------------------------
/resources/DigitalCredentialsAPI-Layering-v20240301.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3c-fedid/digital-credentials/469091ac9ae44101c7a39d8b2b0dba5cf55527db/resources/DigitalCredentialsAPI-Layering-v20240301.pdf


--------------------------------------------------------------------------------
/resources/IdentityCredentialAPI-Layering-2023.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3c-fedid/digital-credentials/469091ac9ae44101c7a39d8b2b0dba5cf55527db/resources/IdentityCredentialAPI-Layering-2023.pdf


--------------------------------------------------------------------------------
/tidyconfig.txt:
--------------------------------------------------------------------------------
1 | char-encoding: utf8
2 | indent: yes
3 | indent-spaces: 2
4 | wrap: 80
5 | tidy-mark: no
6 | custom-tags: yes
7 | 


--------------------------------------------------------------------------------
/w3c.json:
--------------------------------------------------------------------------------
1 | {
2 |   "group":      "wg/fedid",
3 |   "contacts":   ["simoneonofri", "hlflanagan", "wseltzer"],
4 |   "repo-type":  "rec-track"
5 | }
6 | 


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