[feature] eID wallet onboarding restructure #787

Description

@sosweetham

Description

Currently the eID wallet, allows for the verification and pre-verification code flows, in the new design this would change to:

  • Each user begins as an unverified user.
  • The user at onboarding gets an ePassport (a certificate which binds the public key of the user, to their eName)
  • The unverified user also self-signs a binding document tying the hash of their pin/passphrase to their eName
  • From this point the user may procure other binding documents

Binding Documents

Current binding documents which we support are:

  • Physical ID Documents
  • Passphrase/PIN
  • Photograph
  • Friends

Flows to obtain Binding Documents

For Physical ID Documents

Same as the current Veriff flow.

Passphrase/PIN

During onboarding user will self sign a JWT with indefinite expiration which would be hosted at the encrypted secure enclave of the eVault.

Photograph (only works with Veriff flow)

During onboarding with the Veriff flow, our remote CA will sign an assertion or an attestation binding a picture of the face taken during onboarding to the eName of the user.

Friend based

Allow for friends to sign binding documents tying self stated details by a user to their eName

Example

  • Bob onboards using unverified flow
  • Bob claims his name as Bob Smith
  • Bob asks his friend Alice to sign this assertion
  • Alice signs a certificate stating she knows Bob and ties this asserted name to his eName
  • Bob counter-signs this certificate proving a mutual friend relationship

Recovery Flows

Passphrase

Allow for recovery to an eVault if eName is known and the user also holds the passphrase

The passphrase hash shall never be readable and only comparable via some function exposed by the eVault

This function shall be rate-limited and be subject to an exponential back-off to prevent abuse.

Physical ID Document

Current implementation

Friends Based

Allow for a hypothetical eNotary which can read binding documents (except passphrase) and make writes to the eVault's other sectors containing binding documents to help recover an eVault if other options are not viable.

NOTE:
This approach doesn't technically guarantee that either friends or the said notary are not malicious .
This approach also possibly introduces a backdoor to hijack someone's eVault via social engineering and/or malice.
To prevent this said malice a temporary solution would be in place which would prevent friend based recovery without passphrase.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all
       blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
      }
      } catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
      })();
      (function(){
      try {
      var __m = "github.com";
      var __re = new RegExp('^' + "github\\.com" + '
      
      Skip to content

      [feature] eID wallet onboarding restructure #787

      Description

      @sosweetham

      Description

      Currently the eID wallet, allows for the verification and pre-verification code flows, in the new design this would change to:

      • Each user begins as an unverified user.
      • The user at onboarding gets an ePassport (a certificate which binds the public key of the user, to their eName)
      • The unverified user also self-signs a binding document tying the hash of their pin/passphrase to their eName
      • From this point the user may procure other binding documents

      Binding Documents

      Current binding documents which we support are:

      • Physical ID Documents
      • Passphrase/PIN
      • Photograph
      • Friends

      Flows to obtain Binding Documents

      For Physical ID Documents

      Same as the current Veriff flow.

      Passphrase/PIN

      During onboarding user will self sign a JWT with indefinite expiration which would be hosted at the encrypted secure enclave of the eVault.

      Photograph (only works with Veriff flow)

      During onboarding with the Veriff flow, our remote CA will sign an assertion or an attestation binding a picture of the face taken during onboarding to the eName of the user.

      Friend based

      Allow for friends to sign binding documents tying self stated details by a user to their eName

      Example

      • Bob onboards using unverified flow
      • Bob claims his name as Bob Smith
      • Bob asks his friend Alice to sign this assertion
      • Alice signs a certificate stating she knows Bob and ties this asserted name to his eName
      • Bob counter-signs this certificate proving a mutual friend relationship

      Recovery Flows

      Passphrase

      Allow for recovery to an eVault if eName is known and the user also holds the passphrase

      The passphrase hash shall never be readable and only comparable via some function exposed by the eVault

      This function shall be rate-limited and be subject to an exponential back-off to prevent abuse.

      Physical ID Document

      Current implementation

      Friends Based

      Allow for a hypothetical eNotary which can read binding documents (except passphrase) and make writes to the eVault's other sectors containing binding documents to help recover an eVault if other options are not viable.

      NOTE:
      This approach doesn't technically guarantee that either friends or the said notary are not malicious .
      This approach also possibly introduces a backdoor to hijack someone's eVault via social engineering and/or malice.
      To prevent this said malice a temporary solution would be in place which would prevent friend based recovery without passphrase.

      Metadata

      Metadata

      Assignees

      No one assigned

        Labels

        enhancementNew feature or request

        Type

        No type

        Projects

        No projects

          Milestone

          No milestone

          Relationships

          None yet

          Development

          No branches or pull requests

          Issue actions

          , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
          Skip to content

          [feature] eID wallet onboarding restructure #787

          Description

          @sosweetham

          Description

          Currently the eID wallet, allows for the verification and pre-verification code flows, in the new design this would change to:

          • Each user begins as an unverified user.
          • The user at onboarding gets an ePassport (a certificate which binds the public key of the user, to their eName)
          • The unverified user also self-signs a binding document tying the hash of their pin/passphrase to their eName
          • From this point the user may procure other binding documents

          Binding Documents

          Current binding documents which we support are:

          • Physical ID Documents
          • Passphrase/PIN
          • Photograph
          • Friends

          Flows to obtain Binding Documents

          For Physical ID Documents

          Same as the current Veriff flow.

          Passphrase/PIN

          During onboarding user will self sign a JWT with indefinite expiration which would be hosted at the encrypted secure enclave of the eVault.

          Photograph (only works with Veriff flow)

          During onboarding with the Veriff flow, our remote CA will sign an assertion or an attestation binding a picture of the face taken during onboarding to the eName of the user.

          Friend based

          Allow for friends to sign binding documents tying self stated details by a user to their eName

          Example

          • Bob onboards using unverified flow
          • Bob claims his name as Bob Smith
          • Bob asks his friend Alice to sign this assertion
          • Alice signs a certificate stating she knows Bob and ties this asserted name to his eName
          • Bob counter-signs this certificate proving a mutual friend relationship

          Recovery Flows

          Passphrase

          Allow for recovery to an eVault if eName is known and the user also holds the passphrase

          The passphrase hash shall never be readable and only comparable via some function exposed by the eVault

          This function shall be rate-limited and be subject to an exponential back-off to prevent abuse.

          Physical ID Document

          Current implementation

          Friends Based

          Allow for a hypothetical eNotary which can read binding documents (except passphrase) and make writes to the eVault's other sectors containing binding documents to help recover an eVault if other options are not viable.

          NOTE:
          This approach doesn't technically guarantee that either friends or the said notary are not malicious .
          This approach also possibly introduces a backdoor to hijack someone's eVault via social engineering and/or malice.
          To prevent this said malice a temporary solution would be in place which would prevent friend based recovery without passphrase.

          Metadata

          Metadata

          Assignees

          No one assigned

            Labels

            enhancementNew feature or request

            Type

            No type

            Projects

            No projects

              Milestone

              No milestone

              Relationships

              None yet

              Development

              No branches or pull requests

              Issue actions

              , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
              Skip to content

              [feature] eID wallet onboarding restructure #787

              Description

              @sosweetham

              Description

              Currently the eID wallet, allows for the verification and pre-verification code flows, in the new design this would change to:

              • Each user begins as an unverified user.
              • The user at onboarding gets an ePassport (a certificate which binds the public key of the user, to their eName)
              • The unverified user also self-signs a binding document tying the hash of their pin/passphrase to their eName
              • From this point the user may procure other binding documents

              Binding Documents

              Current binding documents which we support are:

              • Physical ID Documents
              • Passphrase/PIN
              • Photograph
              • Friends

              Flows to obtain Binding Documents

              For Physical ID Documents

              Same as the current Veriff flow.

              Passphrase/PIN

              During onboarding user will self sign a JWT with indefinite expiration which would be hosted at the encrypted secure enclave of the eVault.

              Photograph (only works with Veriff flow)

              During onboarding with the Veriff flow, our remote CA will sign an assertion or an attestation binding a picture of the face taken during onboarding to the eName of the user.

              Friend based

              Allow for friends to sign binding documents tying self stated details by a user to their eName

              Example

              • Bob onboards using unverified flow
              • Bob claims his name as Bob Smith
              • Bob asks his friend Alice to sign this assertion
              • Alice signs a certificate stating she knows Bob and ties this asserted name to his eName
              • Bob counter-signs this certificate proving a mutual friend relationship

              Recovery Flows

              Passphrase

              Allow for recovery to an eVault if eName is known and the user also holds the passphrase

              The passphrase hash shall never be readable and only comparable via some function exposed by the eVault

              This function shall be rate-limited and be subject to an exponential back-off to prevent abuse.

              Physical ID Document

              Current implementation

              Friends Based

              Allow for a hypothetical eNotary which can read binding documents (except passphrase) and make writes to the eVault's other sectors containing binding documents to help recover an eVault if other options are not viable.

              NOTE:
              This approach doesn't technically guarantee that either friends or the said notary are not malicious .
              This approach also possibly introduces a backdoor to hijack someone's eVault via social engineering and/or malice.
              To prevent this said malice a temporary solution would be in place which would prevent friend based recovery without passphrase.

              Metadata

              Metadata

              Assignees

              No one assigned

                Labels

                enhancementNew feature or request

                Type

                No type

                Projects

                No projects

                  Milestone

                  No milestone

                  Relationships

                  None yet

                  Development

                  No branches or pull requests

                  Issue actions

                  , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
                  Skip to content

                  [feature] eID wallet onboarding restructure #787

                  Description

                  @sosweetham

                  Description

                  Currently the eID wallet, allows for the verification and pre-verification code flows, in the new design this would change to:

                  • Each user begins as an unverified user.
                  • The user at onboarding gets an ePassport (a certificate which binds the public key of the user, to their eName)
                  • The unverified user also self-signs a binding document tying the hash of their pin/passphrase to their eName
                  • From this point the user may procure other binding documents

                  Binding Documents

                  Current binding documents which we support are:

                  • Physical ID Documents
                  • Passphrase/PIN
                  • Photograph
                  • Friends

                  Flows to obtain Binding Documents

                  For Physical ID Documents

                  Same as the current Veriff flow.

                  Passphrase/PIN

                  During onboarding user will self sign a JWT with indefinite expiration which would be hosted at the encrypted secure enclave of the eVault.

                  Photograph (only works with Veriff flow)

                  During onboarding with the Veriff flow, our remote CA will sign an assertion or an attestation binding a picture of the face taken during onboarding to the eName of the user.

                  Friend based

                  Allow for friends to sign binding documents tying self stated details by a user to their eName

                  Example

                  • Bob onboards using unverified flow
                  • Bob claims his name as Bob Smith
                  • Bob asks his friend Alice to sign this assertion
                  • Alice signs a certificate stating she knows Bob and ties this asserted name to his eName
                  • Bob counter-signs this certificate proving a mutual friend relationship

                  Recovery Flows

                  Passphrase

                  Allow for recovery to an eVault if eName is known and the user also holds the passphrase

                  The passphrase hash shall never be readable and only comparable via some function exposed by the eVault

                  This function shall be rate-limited and be subject to an exponential back-off to prevent abuse.

                  Physical ID Document

                  Current implementation

                  Friends Based

                  Allow for a hypothetical eNotary which can read binding documents (except passphrase) and make writes to the eVault's other sectors containing binding documents to help recover an eVault if other options are not viable.

                  NOTE:
                  This approach doesn't technically guarantee that either friends or the said notary are not malicious .
                  This approach also possibly introduces a backdoor to hijack someone's eVault via social engineering and/or malice.
                  To prevent this said malice a temporary solution would be in place which would prevent friend based recovery without passphrase.

                  Metadata

                  Metadata

                  Assignees

                  No one assigned

                    Labels

                    enhancementNew feature or request

                    Type

                    No type

                    Projects

                    No projects

                      Milestone

                      No milestone

                      Relationships

                      None yet

                      Development

                      No branches or pull requests

                      Issue actions

                      , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
                      Skip to content

                      [feature] eID wallet onboarding restructure #787

                      Description

                      @sosweetham

                      Description

                      Currently the eID wallet, allows for the verification and pre-verification code flows, in the new design this would change to:

                      • Each user begins as an unverified user.
                      • The user at onboarding gets an ePassport (a certificate which binds the public key of the user, to their eName)
                      • The unverified user also self-signs a binding document tying the hash of their pin/passphrase to their eName
                      • From this point the user may procure other binding documents

                      Binding Documents

                      Current binding documents which we support are:

                      • Physical ID Documents
                      • Passphrase/PIN
                      • Photograph
                      • Friends

                      Flows to obtain Binding Documents

                      For Physical ID Documents

                      Same as the current Veriff flow.

                      Passphrase/PIN

                      During onboarding user will self sign a JWT with indefinite expiration which would be hosted at the encrypted secure enclave of the eVault.

                      Photograph (only works with Veriff flow)

                      During onboarding with the Veriff flow, our remote CA will sign an assertion or an attestation binding a picture of the face taken during onboarding to the eName of the user.

                      Friend based

                      Allow for friends to sign binding documents tying self stated details by a user to their eName

                      Example

                      • Bob onboards using unverified flow
                      • Bob claims his name as Bob Smith
                      • Bob asks his friend Alice to sign this assertion
                      • Alice signs a certificate stating she knows Bob and ties this asserted name to his eName
                      • Bob counter-signs this certificate proving a mutual friend relationship

                      Recovery Flows

                      Passphrase

                      Allow for recovery to an eVault if eName is known and the user also holds the passphrase

                      The passphrase hash shall never be readable and only comparable via some function exposed by the eVault

                      This function shall be rate-limited and be subject to an exponential back-off to prevent abuse.

                      Physical ID Document

                      Current implementation

                      Friends Based

                      Allow for a hypothetical eNotary which can read binding documents (except passphrase) and make writes to the eVault's other sectors containing binding documents to help recover an eVault if other options are not viable.

                      NOTE:
                      This approach doesn't technically guarantee that either friends or the said notary are not malicious .
                      This approach also possibly introduces a backdoor to hijack someone's eVault via social engineering and/or malice.
                      To prevent this said malice a temporary solution would be in place which would prevent friend based recovery without passphrase.

                      Metadata

                      Metadata

                      Assignees

                      No one assigned

                        Labels

                        enhancementNew feature or request

                        Type

                        No type

                        Projects

                        No projects

                          Milestone

                          No milestone

                          Relationships

                          None yet

                          Development

                          No branches or pull requests

                          Issue actions

                          , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
                          Skip to content

                          [feature] eID wallet onboarding restructure #787

                          Description

                          @sosweetham

                          Description

                          Currently the eID wallet, allows for the verification and pre-verification code flows, in the new design this would change to:

                          • Each user begins as an unverified user.
                          • The user at onboarding gets an ePassport (a certificate which binds the public key of the user, to their eName)
                          • The unverified user also self-signs a binding document tying the hash of their pin/passphrase to their eName
                          • From this point the user may procure other binding documents

                          Binding Documents

                          Current binding documents which we support are:

                          • Physical ID Documents
                          • Passphrase/PIN
                          • Photograph
                          • Friends

                          Flows to obtain Binding Documents

                          For Physical ID Documents

                          Same as the current Veriff flow.

                          Passphrase/PIN

                          During onboarding user will self sign a JWT with indefinite expiration which would be hosted at the encrypted secure enclave of the eVault.

                          Photograph (only works with Veriff flow)

                          During onboarding with the Veriff flow, our remote CA will sign an assertion or an attestation binding a picture of the face taken during onboarding to the eName of the user.

                          Friend based

                          Allow for friends to sign binding documents tying self stated details by a user to their eName

                          Example

                          • Bob onboards using unverified flow
                          • Bob claims his name as Bob Smith
                          • Bob asks his friend Alice to sign this assertion
                          • Alice signs a certificate stating she knows Bob and ties this asserted name to his eName
                          • Bob counter-signs this certificate proving a mutual friend relationship

                          Recovery Flows

                          Passphrase

                          Allow for recovery to an eVault if eName is known and the user also holds the passphrase

                          The passphrase hash shall never be readable and only comparable via some function exposed by the eVault

                          This function shall be rate-limited and be subject to an exponential back-off to prevent abuse.

                          Physical ID Document

                          Current implementation

                          Friends Based

                          Allow for a hypothetical eNotary which can read binding documents (except passphrase) and make writes to the eVault's other sectors containing binding documents to help recover an eVault if other options are not viable.

                          NOTE:
                          This approach doesn't technically guarantee that either friends or the said notary are not malicious .
                          This approach also possibly introduces a backdoor to hijack someone's eVault via social engineering and/or malice.
                          To prevent this said malice a temporary solution would be in place which would prevent friend based recovery without passphrase.

                          Metadata

                          Metadata

                          Assignees

                          No one assigned

                            Labels

                            enhancementNew feature or request

                            Type

                            No type

                            Projects

                            No projects

                              Milestone

                              No milestone

                              Relationships

                              None yet

                              Development

                              No branches or pull requests

                              Issue actions

                              , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
                              Skip to content

                              [feature] eID wallet onboarding restructure #787

                              Description

                              @sosweetham

                              Description

                              Currently the eID wallet, allows for the verification and pre-verification code flows, in the new design this would change to:

                              • Each user begins as an unverified user.
                              • The user at onboarding gets an ePassport (a certificate which binds the public key of the user, to their eName)
                              • The unverified user also self-signs a binding document tying the hash of their pin/passphrase to their eName
                              • From this point the user may procure other binding documents

                              Binding Documents

                              Current binding documents which we support are:

                              • Physical ID Documents
                              • Passphrase/PIN
                              • Photograph
                              • Friends

                              Flows to obtain Binding Documents

                              For Physical ID Documents

                              Same as the current Veriff flow.

                              Passphrase/PIN

                              During onboarding user will self sign a JWT with indefinite expiration which would be hosted at the encrypted secure enclave of the eVault.

                              Photograph (only works with Veriff flow)

                              During onboarding with the Veriff flow, our remote CA will sign an assertion or an attestation binding a picture of the face taken during onboarding to the eName of the user.

                              Friend based

                              Allow for friends to sign binding documents tying self stated details by a user to their eName

                              Example

                              • Bob onboards using unverified flow
                              • Bob claims his name as Bob Smith
                              • Bob asks his friend Alice to sign this assertion
                              • Alice signs a certificate stating she knows Bob and ties this asserted name to his eName
                              • Bob counter-signs this certificate proving a mutual friend relationship

                              Recovery Flows

                              Passphrase

                              Allow for recovery to an eVault if eName is known and the user also holds the passphrase

                              The passphrase hash shall never be readable and only comparable via some function exposed by the eVault

                              This function shall be rate-limited and be subject to an exponential back-off to prevent abuse.

                              Physical ID Document

                              Current implementation

                              Friends Based

                              Allow for a hypothetical eNotary which can read binding documents (except passphrase) and make writes to the eVault's other sectors containing binding documents to help recover an eVault if other options are not viable.

                              NOTE:
                              This approach doesn't technically guarantee that either friends or the said notary are not malicious .
                              This approach also possibly introduces a backdoor to hijack someone's eVault via social engineering and/or malice.
                              To prevent this said malice a temporary solution would be in place which would prevent friend based recovery without passphrase.

                              Metadata

                              Metadata

                              Assignees

                              No one assigned

                                Labels

                                enhancementNew feature or request

                                Type

                                No type

                                Projects

                                No projects

                                  Milestone

                                  No milestone

                                  Relationships

                                  None yet

                                  Development

                                  No branches or pull requests

                                  Issue actions