<html><head></head><body><div class="ydp831587ceyahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;"><div><div dir="ltr" data-setdir="false"><div>Hi, a fascinating discussion that addresses many important topics.<br><br>Several points:<br><br>- Verifiable Presentation is defined in the W3C Verifiable Credential data model (https://www.w3.org/TR/vc-data-model/#presentations) and is an envelope that carries additional information (Verifiable Credentials, proof of possession)<br><br>- Verifiable Credential data model (defined in the same document) is also generic. VC can hold anything from Diploma attestation, driver's license, eID, ... What information will a VC hold depends on the use case.<br><br>- The fact that the VP requires a proof-of-possession doesn't exclude the possibility to hold a proof-of-presence as a VC.<br><br>- What exactly should be the VP content depends both on the use case and the trust framework. (as said, the VP/VC data models are generic enough to support a wide range of use cases and business or security requirements).<br><br>- ZKP can be interactive or non-interactive. Again, depending on the business/security requirements, use cases will support one or both. The current OIDC4VC proposal covers the case with non-interactive ZKP. Having a generic scheme for the interactive ZKP is a bit more complex as the number of message exchanges depends on the ZKP type.<br><br>- "How do the claims in the VC can be bound to an ephemeral identifier and keys in a trustworthy manner when presented to the RP. (What is being written in the current Claims Aggregation draft is a way of achieving it in the context of regular OIDC response but it cannot be done independently of the verified claims issuance.)"<br>>> Short-lived VCs (as described by David C.)<br>>> Long-lived VCs - If the issuer is not involved, it is not possible.<br><br>- Verifiable Presentation and Verifiable Credentials validation process (not addressed explicitly) will depend on the Trust Framework and is usually a complex process (from validating the VC to verifying the issuer accreditations, non-revocation, ...)<br><br>- Case when Subject != Holder -> This is not covered explicitly. However, a (short-/long-lived) Verifiable Mandate can be issued by the Subject to the Holder.<br><br>VCs/VPs are designed in a very generic way (with some limitations) and can cover a wide range of use cases (I still need to study the aggregated claims specs a bit to create an objective comparison). Many use cases already use/implement the VCs/VPs and also the currently not-standardized version of the OIDC SIOP (sometimes called DID SIOP) to take advantage of the very well designed authentication protocol and to avoid re-inventing the wheel.<br><div><br></div>And we're just scratching the surface :) (assurance levels, long term validity, revocations, resistance to cryptographic suite obsoletion, ...)</div><div><br></div></div><div dir="ltr" data-setdir="false">BR, Alen<br></div><div class="ydp831587cesignature"><div><br></div></div></div>
        <div><br></div><div><br></div>
        
        </div><div id="yahoo_quoted_1804116600" class="yahoo_quoted">
            <div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
                
                <div>
                    On Saturday, 15 May 2021, 03:54:34 CEST, David Waite via Openid-specs-ab <openid-specs-ab@lists.openid.net> wrote:
                </div>
                <div><br></div>
                <div><br></div>
                <div><div dir="ltr"><br clear="none"><br clear="none">> On May 14, 2021, at 7:15 PM, Tom Jones <<a shape="rect" ymailto="mailto:thomasclinganjones@gmail.com" href="mailto:thomasclinganjones@gmail.com">thomasclinganjones@gmail.com</a>> wrote:<br clear="none">> <br clear="none">> DW - A verifiable presentation is defined in terms of a mandated cryptographic proof. Externalized biometrics (e.g. photo in the credential) are effectively a separate proof external to VC/VP that the holder is the subject. We could eventually have cryptographic means of verifying this via secure wallets.<br clear="none">> <br clear="none">> TJ - I certainly hope we can focus strongly on this. AFAIK (DW?) the dpop is only proof of possession and so does not meet proof-of-presence. I plan to push OIDF hard in the direction of active proof-of-possession from certified apps on well-known smartphones. This will become critical when a mobile driver's license can get you access to a nuclear power plant, which is a goal of the current DHS RFC. I think that the next spec from OIDF needs to enable this.<br clear="none">> <br clear="none">I agree, and do not like divulging biometric data just to have this process be external.<br clear="none"><br clear="none">My hope is that mDL requirements (which I’m still coming up to speed on) will push platforms to support binding a particular biometric to the credential. Today, the binding is to a mutable set of authentication methods - I can always temporarily share my PIN or add a fingerprint to the list of allowed authentication methods, and this isn’t necessarily represented to a wallet application via public API.<br clear="none"><br clear="none">There may also be lower assurance ways which would not be quite so fragile (in terms of causing credentials to be invalidated due to setting changes or device migrations.)<br clear="none"><br clear="none">My hope is that we can isolate the issuer binding a credential with the holder in a similar way to how we isolate the authentication and authorization consent processes at the OP/AS, so that this evolution does not need to happen directly within OIDC specs.<div class="yqt5252128710" id="yqtfd05658"><br clear="none"><br clear="none">-DW<br clear="none">_______________________________________________<br clear="none">Openid-specs-ab mailing list<br clear="none"><a shape="rect" ymailto="mailto:Openid-specs-ab@lists.openid.net" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br clear="none"><a shape="rect" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br clear="none"></div></div></div>
            </div>
        </div></body></html>