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://datatracker.ietf.org/doc/draft-demarco-status-attestations/>
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://datatracker.ietf.org/doc/draft-demarco-status-attestations/>
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=40gmx....@dmarc.ietf.org> 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 <oauth-boun...@ietf.org> *On Behalf Of *Orie Steele
*Sent:* Mittwoch, 17. Jänner 2024 19:07
*To:* sp...@ietf.org
*Cc:* oauth <oauth@ietf.org>
*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
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/
Is also relevant to this draft.
I also learned that
https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/
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://www.w3.org/ns/credentials/examples/v2";
],
"id": "http://university.example/credentials/1872";,
"type": ["VerifiableCredential", "ExampleAlumniCredential"],
...
}
The credential type in RDF becomes
"https://www.w3.org/ns/credentials/examples#ExampleAlumniCredential";
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";,
"given_name": "John",
"family_name": "Doe",
"email": "john...@example.com",
"phone_number": "+1-202-555-0101",
"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 <http://www.transmute.industries>
<https://transmute.industries/>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
