Hi Giuseppe,
Ciao Denis,
Thank you! By points.
First, I still have a vocabulary problem. The text states:
A *digital credential* may be presented to a verifier long after it
has been issued.
It should rather say: A *digital proof *(derived from a digital
credential) may be presented to a verifier.
Then, the text states:
Verifier:
Entity that relies on the validity of the Digital Credentials
presented to it.
I should rather say:
Verifier:
Entity that relies on the validity of the *digital proof*
presented to it.
OAuth Status List can be accessed by a Verifier when an internet
connection is present.
*
This does not correspond to the flows of the figure.
the section enumerates the differences between oauth status list and
oauth status attestations.
The subject of the sentence is then the oauth status list, below I
report the original text in that point:
*Offline flow*: OAuth Status List can be accessed by a Verifier when
an internet connection is present. At the same time, OAuth Status List
defines how to provide a static Status List Token, to be included
within a Digital Credential. This requires the Wallet Instance to
acquire a new Digital Credential for a specific presentation. Even if
similar to the OAuth Status List Token, the Status Attestations enable
the User to persistently use their preexistent Digital Credentials, as
long as the linked Status Attestation is available and presented to
the Verifier, and not expired.
OK.
* What about the support of "blinded link secrets" and "link
secrets" (used with anonymous credentials) ?
Unfortunately I don't have these in the EUDI ARF and in my
implementative asset but this doesn't prevent us to not include it in
the draft.
When writing this, I had the use case of BBS+ in mind.
Published versions of the ARF is available here:
https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/arf.md
The word "privacy" is used once in a single sentence copied below which is:
Attestation exchange Protocol. This protocol defines how to request
and present the PID and the (Q)EAA in a secure and *privacy*
preserving fashion.
In the context of a single data controller, ISO 29100 identifies eleven
privacy principles:
1. Consent and choice
2. Purpose legitimacy and specification
3. Collection limitation
4. Data minimization
5. Use, retention and disclosure limitation
6. Accuracy and quality
7. Openness, transparency and notice
8. Individual participation and access
9. Accountability
10. Information security
11. Privacy compliance
None of them is being addressed.
In addition, when considering a distributed system used by human beings,
*two additional **privacy principles *need to be taken into consideration
and none of them is mentioned:
* Unlinkability *of holders between verifiers
* Untrackability* of holders by a server, (i.e., a property
ensuring that it is not possible for a server to know by which verifier
the information it issues to a caller,
or derivations from it, will be
consumed. In other words : Can the server act as Big Brother ?
Margrethe*Vestager*, [former] Executive Vice-President for a Europe Fit
for the Digital Age said:
/ “The European digital identity will enable us to do in any Member
State as we do at home without any extra cost and fewer hurdles. /
/ Be that renting a flat or opening a bank account outside of our
home country. And do this in a way that is secure and transparent. /
/*S**o that we will decide how much information we wish to share about
ourselves, with whom and for what purpose.*/
Source: https://ec.europa.eu/commission/presscorner/detail/en/ip_21_2663
**
This statement is not mentioned in the ARF.
An additional important *security consideration *needs to be addressed:
* Collusions between **holders *(natural persons), which is
difficult to support while at the same time the "*collection
limitation*" privacy principle is considered.
This can be illustrated by the following example:
Can Alice (12) collude with Bob (25) to access to a verifier
delivering age-restricted services or products (e.g., like the condition
of being over 18) ?
Since Bob is over 25, he can obtain some "proof" that he is over
18. Can Alice (12) can advantage of this proof to access to
age-restricted services or products ?
Would you like to propose your idea in the current text (github issue
or PR) about the possibility to enable this technology?
On page 45 from COM(2021) 281 final,
(https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:52021PC0281)
there is the following statement:
" A strengthened *privacy-by-design approach* could yield
additional benefits since the wallet would not require intermediaries
in the process of asserting the attributes, thus enabling
the citizen to communicate directly with the service and credential
providers".
Every IETF draft now includes both a *Security Consideration* section
and a *Privacy Consideration *section. There is no such sections in ARF
1.0.X.
Since ARF 1.0.X has not listed any privacy principle, it could not
follow a *privacy-by-design approach.*
Before defining technical solutions, requirements would first need to be
identified and agreed. At the moment, none of the five experiments is
considering
the previously identified privacy principles (nor the above security
consideration).
There should first be an agreement to add both a *Security
Consideration* section and a *Privacy Consideration *section to the ARF.
Another consideration has been raised: the cryptographic algorithms
being used should be quantum resistant.
This is a good wish but nobody knows when this would really be needed.
BBS+ is not believed to be quantum resistant. However, if one-time
digital signatures are considered, they can be quantum resistant
(e.g., using SHA-3 and Lamport signatures). This would natively prevent
verifiers to use the public key present in a credential proof to link
accesses from
the same holder on different servers. This would mandate to issue
batches of credentials in advance, which is only considered at a
possible /option/
at the moment. This would also prevent using a "digital credential
serial number" to perform a linkage between different digital proofs.
For signing digital credentials, the FIPS 204 (DRAFT)
MODULE-LATTICE-BASED DIGITAL SIGNATURE STANDARD might be considered.
This does not mean in anyway that these algorithms should be used *now*,
but it would be good to already know which kinds algorithms will be usable
when it will become really necessary to achieve quantum resistance.
I mean, the current text satisfies the security requirements, in
addition to this we can explore and enable additional methods, in
particular when these brings additional benefits.
* A major section is missing: "*Privacy considerations*".
yes, the best is yet to come ��
When doing a *privacy-and-security-by-design *approach*, *once the model
and the key actors have be identified, these two sections should be
filled-in first.
:-)
* One of many privacy principles is: "unlinkability between verifiers".
yes. The scope of this specs is providing a "static" way to give a
verifiable proof. In the privacy consideration I would start with the
sotry of Giuseppe that presents his credential of org affiliation to
an RP, giving org name, entitlements and position. Having the url and
the index of the revocation status of that credential, the RP is
technically able to continuosly check that Giuseppe is still emploied
in that organization, even outside of a resonable time windows for the
authorized authentication/session.
then, the scopes of this draft is all about revocation and tracking
prevention about the revocation checks. The problem of linkability
belongs to the credential and not to the status attestation (if I
didn't miss anything).
Let us now come back to Status Attestations when using one-time digital
credentials.
Let us consider two cases: whether the status attestation request is
done by the holder or by the verifier.
1) If the status attestation request is done by the holder, this means
that it is online and in such a case, it could ask for a batch of
one-time digital credentials
with short expiration dates without the need to request Status
Attestations.
2) If the status attestation request is done by the verifier /and if the
server able to provide Status Attestations is different from the server
issuing the digital credential/,
then a query to that other server will prevent the issuer to know
where the digital proof has been presented by the holder. This would
allow the holder to get
digital credentials with longer expiration dates.
Seen from the wallet, the following strategy would be used:
* If the wallet knows that it is on-line, it will use or request a
digital credential with a short expiration date.
This will avoid the verifier to make a call when it receives the
digital proof.
* If the wallet knows that it is off-line, it will use an already
stored digital credential with a long expiration date.
If the server able to provide Status Attestations is, in fact, not
really independent from the server issuing the digital credential,
the linkability between verifiers will be limited to servers
accessed using NFC. Hence, the risk will be mitigated.
Both types of digital credential will then have their own merits.
Yes, I will, The sections Rationale and Privacy Consideration are the
most funny and we'll continue on those. Thank you for the hints, I
appreciate!
In this rather long email, you have further hints.
:-)
Denis
------------------------------------------------------------------------
*Da:* Denis <denis.i...@free.fr>
*Inviato:* giovedì 18 gennaio 2024 19:25
*A:* demarcog83 <demarco...@gmail.com>
*Cc:* sp...@ietf.org <sp...@ietf.org>; Giuseppe De Marco
<gi.dema...@innovazione.gov.it>; oauth <oauth@ietf.org>
*Oggetto:* Re: [SPICE] [OAUTH-WG] OAuth Digital Credential Status
Attestations (typo)
Non si ricevono spesso messaggi di posta elettronica da
denis.i...@free.fr. Informazioni sul perché è importante
<https://aka.ms/LearnAboutSenderIdentification>
Questa email arriva da un mittente insolito. Assicurati che sia
qualcuno di cui ti fidi.
Giuseppe,
You are perfectly right, I read your draft too quickly.
1) The text mentions near the end:
OAuth Status List can be accessed by a Verifier when an internet
connection is present.
This does not correspond to the flows of the figure.
2) The text states:
" The proof of possession MUST be signed with the private key
corresponding to the *public key* attested by the Issuer
and contained within the Credential".
What about the support of "blinded link secrets" and "link secrets"
(used with anonymous credentials) ?
3) A major section is missing: "*Privacy considerations*".
One of many privacy principles is: "unlinkability between verifiers".
If or when the status attestation allows to support this privacy
principle, it should be indicated how it can be supported.
If or when it does not, this should be mentioned as well.
Denis
Ciao Denis,
thank you for the quick reply and for your contribution.
The scope of the current draft is to provide a verifiable artifact
that give the proof that a specific credential is active, then not
revoked.
From your sequence diagram I read a digital credential issuance,
while this is not in the scope of the draft.
best
Il giorno gio 18 gen 2024 alle ore 10:26 Denis <denis.i...@free.fr
<mailto:denis.i...@free.fr>> ha scritto:
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=40gmx....@dmarc.ietf.org
<mailto: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
<mailto:oauth-boun...@ietf.org>> *On Behalf Of *Orie Steele
*Sent:* Mittwoch, 17. Jänner 2024 19:07
*To:* sp...@ietf.org <mailto:sp...@ietf.org>
*Cc:* oauth <oauth@ietf.org <mailto: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
<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": "john...@example.com <mailto: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
<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
OAuth@ietf.org <mailto:OAuth@ietf.org>
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 list
OAuth@ietf.org <mailto:OAuth@ietf.org>
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 list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
