Re: [OAUTH-WG] [SPICE] OAuth Digital Credential Status Attestations (typo)

[Tom Jones <[e-mail]>]

it is very presumptuous for you to tell the verifier what they must do.
Why do you think they will pay any attention to you?
Be the change you want to see in the world ..tom


On Thu, Jan 18, 2024 at 10:39 AM Giuseppe De Marco <
[e-mail]> wrote:

> Hi Tom,
>
> let's try to align ourself, then it will be more natural.
>
> The Verifier has the requirement to verify the validitiy of the
> presentations and verify that the credentials are still valid and then not
> revoked. This is the "what".
>
> The "how" can bring several solutions:
>
>
>    - OAuth Status List for realtime checks where the RP interacts
>    directly with the status list provider
>    - OAuth Status Attestation where the RP interacts  directly with the
>    wallet instance
>
>
> The flows above are definitely different, first of all the entities
> involved are different. Since the wallet instance must provide the
> presentation, it also adds the attestations about the non revocation of
> these, in a single shot. It works also in proxmity flow, where the Verifier
> doesn't have internet (since it can establish the trust with the wallet
> solution and the credential issuer just by having the public key of the
> Trust Anchor ... old story!).
>
> In terms of presentation request the RP would not add the status
> attestation in the presentation definition, if the credential carries the
> status.status_attestation object this is the element that gives to the RP
> the hint to looks in the vp_tokens for the status attestation.
>
> and they all lived happily ever after, please help me find some problem
>
>
> ------------------------------
> *Da:* Tom Jones <[e-mail]>
> *Inviato:* giovedì 18 gennaio 2024 18:43
> *A:* Denis <[e-mail]>
> *Cc:* demarcog83 <[e-mail]>; hannes.tschofenig=
> [e-mail] <hannes.tschofenig=[e-mail]>;
> [e-mail] <[e-mail]>; Francesco Antonio Marino <
> [e-mail]>; Giuseppe De Marco <[e-mail]>;
> oauth <[e-mail]>
> *Oggetto:* Re: [OAUTH-WG] [SPICE] OAuth Digital Credential Status
> Attestations (typo)
>
> Non si ricevono spesso messaggi di posta elettronica da
> [e-mail]. Informazioni sul perché è importante
> <https://aka.ms/LearnAboutSenderIdentification>
>
> The big problem is that standards bodies all over the spectrum are
> creating attestations without even bothering to see what is happening in
> other communities. The verifier will have many attestations to choose from
> and will thus choose to do nothing with any of them. Perhaps it is time to
> ask a verifier what problems they have instead of telling how to fix
> problems they don't have currently? If it is really this hard to get this
> new stuff to work, perhaps the new stuff is not well-designed to begin
> with? ..tom
>
>
> On Thu, Jan 18, 2024 at 1:27 AM Denis <[e-mail]> wrote:
>
> Typo: Change: "proof *or* origin of wallet instance"
> into               : "proof * of* origin of wallet instance".
>
> The figure has been corrected below.
>
> Denis
>
> Hi Giuseppe,
>
> The current figure in the Introduction from
> draft-demarco-status-attestations-latest is:
>
> +-----------------+                             +-------------------+
> |                 | Requests Status Attestation |                   |
> |                 |---------------------------->|                   |
> | Wallet Instance |                             | Credential Issuer |
> |                 | Status Attestation          |                   |
> |                 |<----------------------------|                   |
> +-----------------+                             +-------------------+
>
>
> +-- ----------------+                             +----------+
> |                   | Presents credential and     |          |
> |  Wallet Instance  | Status Attestation          | Verifier |
> |                   |---------------------------->|          |
> +-------------------+                             +----------+
>
> IMO, using the vocabulary agreed during the last BoF video conference,
> this figure should be modified as follows:
>
>
> +------------+
> +-------------------+
> |            | Requests *Digital Credential*            |
> |
> |            | and presents proof of knowledge of     |
> |
> |            | either a private key or a link secret  |
> |
> |            | and proof *of* origin of wallet instance | Credential
> Issuer |
> |   Holder   |--------------------------------------->|
> |
> |            |                                        |
> |
> |            |    *Digital Credential*                  |
> |
> |            |<---------------------------------------|
> |
> +------------+
> +-------------------+
>
>
> +-- ---------+
> +-------------------+
> |            | Presents *Credential proof*              |
>        |
> |   Holder   |                                        |      Verifier
> |
> |            |--------------------------------------->|
> |
> +------------+
> +-------------------+
>
> Denis
>
>
> Hi Hannes,
>
> Thank you for your quick reaction and also to Orie for sharing.
> I've submitted the draft, here:
> https://datatracker.ietf.org/doc/draft-demarco-status-attestations/
>
>
> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-demarco-status-attestations%2F&e=bcb9f84b&h=6cfb1966&f=n&p=y>
> Regarding the term Attestation: good point. We have decided to use this
> term since in several IETF and OpenID drafts this term seems pretty
> established, the term Attestation is found at least in the following
> specifications:
>   - Attestation based client-authentication (it's in the title)
>   - OpenID4VC High Assurance Interoperability Profile with SD-JWT VC
> (wallet attestation)
>   - OpenID for Verifiable Presentations - draft 20 (verifier attestation)
>   - OpenID for Verifiable Credential Issuance (section "Trust between
> Wallet and Issuer": Device Attestation)
>
> Meantime in the eIDAS Expert group this term is going to be changed to
> "Wallet Trust Evidence".
>
>
> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-demarco-status-attestations%2F&e=bcb9f84b&h=6cfb1966&f=n&p=y>
> I don't have a strong opinion on what would be the best semantic for this,
> I just have realized the functional difference between a Digital Credential
> and an Attestation:
> the first requires the user to be authenticated and give consent for using
> the secure storage. The second is obtained with a machine2machine flow
> where no user interaction is required, the secure storage is not required,
> no user information is contained in it since the subject is the wallet
> instance and not the user, it cannot be (re)used without the cryptographic
> proof of possession. Probably a discussion could start about this term
> aiming to align several specifications on the same terminology. I could say
> that Status Attestation is a specific artifact defined for a specific
> context, other attestations can be defined outside the functional perimeter
> of this specification. Let's talk about it, it doesn't matters changing
> terms (eventually mindsets on perceivable meanings).
>
> Here I share some notes I picked along the last two months about this
> brand new individual draft:
>
> - it is related to digital credential only, I don't expect to use it in
> legacy infrastructure different from wallet. I really don't need this kind
> of mechanism in OIDC or any other traditional infrastructure since these
> doesn't show the privacy issues the wallet ecosystem has;
> - it would interesting mentioning in the introduction that's pratically an
> ocsp stapling like mechanism, just to give some context (credit: Paul
> Bastien);
> - The Rationale section needs to clarify better problems and solutions, where
> it seems that the problem does not exist or that it is weak. A review is
> necessary to clearly bring the benefits;
> - Editorials mistake are still along the reading.
>
> thank you for your time and interest,
> best
>
>
>
>
>
>
> Il giorno mer 17 gen 2024 alle ore 21:06 <hannes.tschofenig=
> [e-mail]> ha scritto:
>
> Hi Guiseppe, Francesco, Orie,
>
>
>
> @Orie: Thanks for sharing the draft.
>
>
>
> As a quick reaction: It would be good to invent a new term for
> “attestation” in draft-demarco-status-attestations.html because this term
> is already widely used in a different context (see RFC 9334).
>
>
>
> @Guiseppe and Francesco: It would be great if you could submit your draft
> to OAuth or SPICE for discussion.
>
>
>
> Ciao
>
> Hannes
>
>
>
>
>
> *From:* OAuth <[e-mail]> *On Behalf Of *Orie Steele
> *Sent:* Mittwoch, 17. Jänner 2024 19:07
> *To:* [e-mail]
> *Cc:* oauth <[e-mail]>
> *Subject:* [OAUTH-WG] OAuth Digital Credential Status Attestations
>
>
>
> Hello Digital Credential Enthusiasts,
>
> See:
> https://peppelinux.github.io/draft-demarco-status-attestations/draft-demarco-status-attestations.html
> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fpeppelinux.github.io%2Fdraft-demarco-status-attestations%2Fdraft-demarco-status-attestations.html&e=bcb9f84b&h=09ac1782&f=n&p=y>
>
> Note the use of the term digital credential, and the alignment to CWT
> based credentials and CWT based credential status lists.
>
> As a quick summary of the editors draft above:
>
> It is basically a refresh-token-like approach to dynamic state, where the
> holder retrieves updated state from the issuer at regular intervals, and
> can then present that dynamic state directly to the verifier.
>
> This eliminates the herd privacy and phone home issues associated with W3C
> Bitstring Status Lists.
>
> And it informs the holder of dynamic state, so the digital wallet can
> provide a better user experience.
>
> However, an issuer (government or ngo) could use the interval of
> requesting dynamic state, to track the holder... so the guidance from
> https://datatracker.ietf.org/doc/draft-steele-spice-oblivious-credential-state/
> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-steele-spice-oblivious-credential-state%2F&e=bcb9f84b&h=31ec3f83&f=n&p=y>
>
> Is also relevant to this draft.
>
> I also learned that
> https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/
> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-oauth-sd-jwt-vc%2F&e=bcb9f84b&h=1dd20f32&f=n&p=y>
>
> Has defined a new property for expressing "Verifiable Credential" "type"
> `vct`, which is different from how W3C defines credential types.
>
> W3C uses the expanded IRI for the graph node type, based on the JSON-LD
> context.
>
> For example with:
>
> {
>   "@context": [
>     "https://www.w3.org/ns/credentials/v2
> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.w3.org%2Fns%2Fcredentials%2Fv2&e=bcb9f84b&h=f582aa55&f=n&p=y>
> ",
>     "https://www.w3.org/ns/credentials/examples/v2
> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.w3.org%2Fns%2Fcredentials%2Fexamples%2Fv2&e=bcb9f84b&h=09fd0c99&f=n&p=y>
> "
>   ],
>   "id": "http://university.example/credentials/1872
> <https://urlsand.esvalabs.com/?u=http%3A%2F%2Funiversity.example%2Fcredentials%2F1872&e=bcb9f84b&h=a4458b13&f=n&p=y>
> ",
>   "type": ["VerifiableCredential", "ExampleAlumniCredential"],
>   ...
> }
>
> The credential type in RDF becomes "
> https://www.w3.org/ns/credentials/examples#ExampleAlumniCredential
> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.w3.org%2Fns%2Fcredentials%2Fexamples%23ExampleAlumniCredential&e=bcb9f84b&h=d975b89f&f=n&p=y>
> "
>
> Which is different from "ExampleAlumniCredential" in JSON... More evidence
> that RDF leads to developer confusion regarding safe typing.
>
> The OAuth solution does not have this confusing issue, they set the type
> explicitly:
>
> {
>  "vct": "https://credentials.example.com/identity_credential
> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fcredentials.example.com%2Fidentity_credential&e=bcb9f84b&h=4de83001&f=n&p=y>
> ",
>  "given_name": "John",
>  "family_name": "Doe",
>  "email": "[e-mail]",
>  "phone_number": "[phone]",
>  "address": {
>    "street_address": "123 Main St",
>    "locality": "Anytown",
>    "region": "Anystate",
>    "country": "US"
>  },
>  "birthdate": "1940-01-01",
>  "is_over_18": true,
>  "is_over_21": true,
>  "is_over_65": true,
>  "status": {
>     "status_attestation": {
>         "credential_hash_alg": "S256",
>     }
>  }
> }
>
> Regards,
>
> OS
>
> --
>
>
>
>
> *ORIE STEELE *Chief Technology Officer
> www.transmute.industries
> <https://urlsand.esvalabs.com/?u=http%3A%2F%2Fwww.transmute.industries&e=bcb9f84b&h=5399df5d&f=n&p=y>
>
>
> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Ftransmute.industries%2F&e=bcb9f84b&h=1f9092b6&f=n&p=y>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&e=bcb9f84b&h=b6441af9&f=n&p=y>
>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&e=bcb9f84b&h=b6441af9&f=n&p=y>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&e=bcb9f84b&h=b6441af9&f=n&p=y>
>
>