<div dir="auto">I am not suggesting that there is anything wrong with any VC. I am against adding an explicit way to build any element into siop with out a label that is related to the semantics of the element.<br><br><div data-smartmail="gmail_signature">thx ..Tom (mobile)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 17, 2021, 10:51 AM Alen Horvat <<a href="mailto:horvat.alen@yahoo.com">horvat.alen@yahoo.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px"><div><div dir="ltr">Tom, thank you for the feedback.</div><div dir="ltr"><br></div><div dir="ltr">In your professional opinion, what needs to be improved/fixed? (I'm always trying to take the opportunity and learn/improve things)<br></div><div dir="ltr">Do you maybe have ideas about how to improve/fix things?<br></div><div><div><br></div><div dir="ltr">BR, Alen<br></div></div></div>
<div><br></div><div><br></div>
</div><div id="m_8022134584334238929yahoo_quoted_1521374500">
<div style="font-family:'Helvetica Neue',Helvetica,Arial,sans-serif;font-size:13px;color:#26282a">
<div>
On Monday, 17 May 2021, 19:15:01 CEST, Tom Jones <<a href="mailto:thomasclinganjones@gmail.com" target="_blank" rel="noreferrer">thomasclinganjones@gmail.com</a>> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div id="m_8022134584334238929yiv9409635066"><div><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 clear="none"></div><div>PLEASE DO NOT ALLOW A VC BLOB INTO SIOP - it will surely kill its value.<br clear="none"><div><br clear="all"><div><div dir="ltr"><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,Roboto,Ubuntu,Oxygen,Cantarell,Color UI UI 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 clear="none"></div></div></div><br clear="none"><div><div id="m_8022134584334238929yiv9409635066yqt74658"><div dir="ltr">On Mon, May 17, 2021 at 9:57 AM Alen Horvat via Openid-specs-ab <<a rel="nofollow noopener noreferrer noreferrer" shape="rect" href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br clear="none"></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:Helvetica,Arial,sans-serif;font-size:13px"><div><div dir="ltr"><div>Hi, a fascinating discussion that addresses many important topics.<br clear="none"><br clear="none">Several points:<br clear="none"><br clear="none">- Verifiable Presentation is defined in the W3C Verifiable Credential data model (<a rel="nofollow noopener noreferrer noreferrer" shape="rect" 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 clear="none"><br clear="none">- 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 clear="none"><br clear="none">- 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 clear="none"><br clear="none">- 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 clear="none"><br clear="none">- 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 clear="none"><br clear="none">- "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 clear="none">>> Short-lived VCs (as described by David C.)<br clear="none">>> Long-lived VCs - If the issuer is not involved, it is not possible.<br clear="none"><br clear="none">- 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 clear="none"><br clear="none">- 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 clear="none"><br clear="none">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 clear="none"><div><br clear="none"></div>And we're just scratching the surface :) (assurance levels, long term validity, revocations, resistance to cryptographic suite obsoletion, ...)</div><div><br clear="none"></div></div><div dir="ltr">BR, Alen<br clear="none"></div><div><div><br clear="none"></div></div></div>
<div><br clear="none"></div><div><br clear="none"></div>
</div><div id="m_8022134584334238929yiv9409635066gmail-m_184522314276755292yahoo_quoted_1804116600">
<div style="font-family: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 rel="nofollow noopener noreferrer noreferrer" shape="rect" href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:
</div>
<div><br clear="none"></div>
<div><br clear="none"></div>
<div><div dir="ltr"><br clear="none"><br clear="none">> On May 14, 2021, at 7:15 PM, Tom Jones <<a rel="nofollow noopener noreferrer noreferrer" 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="m_8022134584334238929yiv9409635066gmail-m_184522314276755292yqtfd05658"><br clear="none"><br clear="none">-DW<br clear="none">_______________________________________________<br clear="none">Openid-specs-ab mailing list<br clear="none"><a rel="nofollow noopener noreferrer noreferrer" shape="rect" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br clear="none"><a rel="nofollow noopener noreferrer noreferrer" 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 clear="none">
Openid-specs-ab mailing list<br clear="none">
<a rel="nofollow noopener noreferrer noreferrer" shape="rect" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br clear="none">
<a rel="nofollow noopener noreferrer noreferrer" 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">
</blockquote></div></div>
</div></div></div>
</div>
</div></div></blockquote></div>