[Openid-specs-ab] Verifiable presentation question

[Tom Jones]

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.

thx ..Tom (mobile)

On Mon, May 17, 2021, 10:51 AM Alen Horvat <horvat.alen at yahoo.com> wrote:

> Tom, thank you for the feedback.
>
> In your professional opinion, what needs to be improved/fixed? (I'm always
> trying to take the opportunity and learn/improve things)
> Do you maybe have ideas about how to improve/fix things?
>
> BR, Alen
>
>
> On Monday, 17 May 2021, 19:15:01 CEST, Tom Jones <
> thomasclinganjones at gmail.com> wrote:
>
>
> 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/f1b980a0/attachment.html>