[Openid-specs-digital-credentials-protocols] Security and Trust document
Tom Jones
thomasclinganjones at gmail.com
Thu Sep 14 18:37:39 UTC 2023
All parties communicate with each other using a set of protocols, or just
"protocol" in the following. In the case of OpenID4VP, the protocols are
OpenID for Verifiable Credential Issuance [@!OpenID.VCI] and OpenID for
Verifiable Presentations [@!OpenID.VP], with an optional use of SIOP v2
[@!OpenID.SIOPv2].
thx ..Tom (mobile)
On Thu, Sep 14, 2023, 4:17 AM David Chadwick <d.w.chadwick at truetrust.co.uk>
wrote:
> Hi Tom
>
> if you read my proposed text I think it caters for the use cases you are
> suggesting. If it does not, can you say why not please
>
> thanks
>
> David
> On 14/09/2023 05:35, Tom Jones wrote:
>
> you guys are missing the point - i guess i was not clear.
>
> The current CBP-ONE app is used at the border of the US to schedule
> sessions to acquire asylum. Similarly the child trying to get access to the
> US may need creds. These children are the subjects of credential. They do
> not hold smartphones which are held by (for example) their father as
> guardian. In the US 51 million people do not have smart phones but may need
> digital creds for one reason or another. I suspect that in many countries
> the numbers are even more dire.
>
> If the wallet cannot handle the case where the subject is not the holder,
> then it should not be considered adequate to hold government creds because
> of the many eligible people \who cannot be accommodated.
>
> Somehow this spec (and the rest of the VC specs) needs to address the
> problem where the holder and the subject are not the same person.
>
> ..tom
>
>
> On Wed, Sep 13, 2023 at 3:32 AM David Chadwick via
> Openid-specs-digital-credentials-protocols <
> openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
>
>>
>> On 12/09/2023 20:53, Joseph Heenan via
>> Openid-specs-digital-credentials-protocols wrote:
>>
>> Hi Tom
>>
>> Focussing on this particular document, is your concern resolved if
>> sentences like this:
>>
>> "Identity of Holder: A Verifier can trust that the party presenting the
>> claims in a session with the Verifier is (controlled by) the subject of the
>> claims.”
>>
>> (From
>> https://github.com/vcstuff/oid4vc-security-and-trust/blob/main/draft-oid4vc-security-and-trust.md#trust-in-the-issuer-holder-verifier-model
>> )
>>
>> are replaced with something like this:
>>
>> "Identity of Holder: A Verifier can trust that the party presenting the
>> claims in a session with the Verifier is (controlled by) the party that the
>> credential was intended to be issued to.”
>>
>> I don't think the above is precise enough, since the credential could
>> have been passed from the first holder to the second holder and then to the
>> verifier. Therefore I propose
>>
>> "Identity of Holder: A Verifier can trust that the party presenting the
>> claims in a session with the Verifier is the party who is authorised to
>> hold the credential (from the Verifier's perspective).”
>>
>> The text in parentheses is important for at least the following reasons
>>
>> a) the credential could be a bearer credential
>>
>> b) the verifier may be willing to completely ignore who the issuer
>> intended the credential to be presented by and therefore will allow anyone
>> to present it, e.g. because the verifier gains a benefit from entering into
>> a session with the holder.
>>
>> We have real life examples the above in the physical world.
>>
>> Kind regards
>>
>> David
>>
>>
>> ?
>>
>> Thanks
>>
>> Joseph
>>
>> On 12 Sep 2023, at 16:06, Tom Jones via
>> Openid-specs-digital-credentials-protocols
>> <openid-specs-digital-credentials-protocols at lists.openid.net>
>> <openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
>>
>> One major problem with the OAuth model and this contribution is the
>> conflation of the subject and the holder.
>> To be inclusive these two roles may be entirely different entities.
>> It seems to be that this conflation must be excised if OAuth is to be
>> acceptected as the digital credential model to be used for government
>> supplied rights and privileges.
>>
>> ..tom
>>
>>
>> On Mon, Sep 11, 2023 at 8:14 AM Daniel Fett via
>> Openid-specs-digital-credentials-protocols <
>> openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
>>
>>> Hi all,
>>>
>>> I'd like to contribute the "Security and Trust" document to the DCP WG:
>>> https://github.com/vcstuff/oid4vc-security-and-trust
>>>
>>> It has been discussed earlier, but had no official status so far.
>>>
>>> -Daniel
>>> --
>>> Openid-specs-digital-credentials-protocols mailing list
>>> Openid-specs-digital-credentials-protocols at lists.openid.net
>>>
>>> https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols
>>>
>> --
>> Openid-specs-digital-credentials-protocols mailing list
>> Openid-specs-digital-credentials-protocols at lists.openid.net
>>
>> https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols
>>
>>
>>
>> --
>> Openid-specs-digital-credentials-protocols mailing list
>> Openid-specs-digital-credentials-protocols at lists.openid.net
>>
>> https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20230914/0be9b3d5/attachment-0001.html>
More information about the Openid-specs-digital-credentials-protocols
mailing list