[Openid-specs-ab] Verifiable presentation question

[Tom Jones]

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.

PLEASE DO NOT ALLOW A VC BLOB INTO SIOP - it will surely kill its value.

Be the change you want to see in the world ..tom


On Mon, May 17, 2021 at 9:57 AM Alen Horvat via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Hi, a fascinating discussion that addresses many important topics.
>
> Several points:
>
> - 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)
>
> - 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.
>
> - The fact that the VP requires a proof-of-possession doesn't exclude the
> possibility to hold a proof-of-presence as a VC.
>
> - 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).
>
> - 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.
>
> - "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.)"
> >> Short-lived VCs (as described by David C.)
> >> Long-lived VCs - If the issuer is not involved, it is not possible.
>
> - 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, ...)
>
> - 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.
>
> 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.
>
> And we're just scratching the surface :) (assurance levels, long term
> validity, revocations, resistance to cryptographic suite obsoletion, ...)
>
> BR, Alen
>
>
>
> On Saturday, 15 May 2021, 03:54:34 CEST, David Waite via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
>
>
>
> > On May 14, 2021, at 7:15 PM, Tom Jones <thomasclinganjones at gmail.com>
> wrote:
> >
> > 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.
> >
> > 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.
> >
> I agree, and do not like divulging biometric data just to have this
> process be external.
>
> 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.
>
> 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.)
>
> 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.
>
>
> -DW
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210517/e36357aa/attachment.html>