<div dir="ltr">This list of features is precisely the crap that I do not wish to see dragged into an openID message and why I do not want to allow the inclusion of such an opaque blob into the standard. It will not make OIDC or SIOP more attractive as an authentication method.<div><br></div><div>PLEASE DO NOT ALLOW A VC BLOB INTO SIOP - it will surely kill its value.<br><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap">Be the change you want to see in the world </span>..tom</div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 17, 2021 at 9:57 AM Alen Horvat via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px"><div><div dir="ltr"><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 (<a href="https://www.w3.org/TR/vc-data-model/#presentations" target="_blank">https://www.w3.org/TR/vc-data-model/#presentations</a>) 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">BR, Alen<br></div><div><div><br></div></div></div>
<div><br></div><div><br></div>
</div><div id="gmail-m_184522314276755292yahoo_quoted_1804116600">
<div style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px;color:rgb(38,40,42)">
<div>
On Saturday, 15 May 2021, 03:54:34 CEST, David Waite via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> 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" href="mailto:thomasclinganjones@gmail.com" target="_blank">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 id="gmail-m_184522314276755292yqtfd05658"><br clear="none"><br clear="none">-DW<br clear="none">_______________________________________________<br clear="none">Openid-specs-ab mailing list<br clear="none"><a shape="rect" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">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></div>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>