Hi Giuseppe, Orie and Francesco,
Here is my feedback about the Status Assertion mechanism.
The text of the email states:
"there are several use cases for revocations, each of which is
addressed, either wholly or partially, in these specifications".
While there are indeed several use cases for revocations, I don't
believe that each of them can be addressed
either wholly or partially in these specifications /to the best interest
of the end-users/.
*1) In section 3, a Holder is defined as* :
Holder: An entity that receives Verifiable Credentials and has
control over them to present them to the Verifiers as Verifiable
Presentations.
This definition is ambiguous as it may be understood to be a human-being
(and it is the case later on ...) .
The word "entity" should be changed into "application".
Holder: An application placed in a digital wallet that receives
Verifiable Credentials and has control over them to present them to
the Verifiers as Verifiable Presentations.
*2) The document should first identify the reasons for using a
revocation mechanism*
**
The term "Wallet Instance" is being used and is defined on page 4 as:
The digital wallet in control of a User, also known as Wallet.
So let us consider the use case of a Wallet.
The current document is directly focusing on a technical mechanism
without telling what the problems to be solved are.
Two entities can take the initiative of a revocation : either the owner
of a wallet (i.e., not the Holder) or the Issuer.
Let us focus about the owner of a wallet and its relationship with his
wallet.
The following situations can typically happen :
(1) Where is my wallet ? I can't find it any more. Either I simply
lost it or somebody has stolen it.
(2) My wallet has indeed been stolen. I am sure about this, but I
know that the thief is not in possession of the authentication
factor(s) to use it.
(3) My wallet has indeed been stolen and unfortunately I do know
that the thief is in possession of the authentication factor(s) to
use it.
For each of these cases, should the owner of a wallet ask the Issuer to
revoke of his digital credential ?
In the first case (1), let us suppose that the digital credential is
revoked. Using the Status Assertion mechanism, the revocation will
remain valid
approximately 24 hours. If five minutes after successfully asking
the revocation of that digital credential, the lost wallet is found
again,
the digital credential cannot be used during the next 24 hours. A
new digital credential request must then be initiated.
If a suspension mechanism were available, the new digital credential
request would be avoided.
In the case (2), if the Wallet has been found again a similar
situation applies.
If a suspension mechanism were available, the new digital credential
request would be avoided.
In the case (3), a revocation for much more than 24 hours is needed.
A new digital wallet must be obtained and then after new digital
credential request must be initiated.
*3) The current title of this draft is "OAuth Status Assertions". *
**
The content of the draft is not specific to OAuth specifically. However,
Status Assertions are specific to the use of Digital Credentials.
If a SPICE WG is created by the IESG (which should be known at the end
of this week), the title of this document would become:
"SPICE Status Assertions".
:-)
More seriously, its title should rather be "Credential Status
Assertions" or "Digital Credential Status Assertions".
*4) In section 6. Proof of Possession of a Credential, the text states:*
The essence of requiring proof of possession over the Credential
through the confirmation method,
such has proving the control of the cryptographic material related
to a Credential, is to ensure that the entity
in possession of the Credential can execute actions exclusively
reserved to the legitimate Holder.
Note that the term "Holder" is used above in the sense of a person,
whereas a Holder is an application.
On the contrary, this method *does not* "ensure that the entity in
possession of the Credential can execute actions
exclusively reserved to the legitimate owner of the Credential ". When a
selective disclosure of claims is being done,
PoP, as described, is *not* resistant to collaborative attacks between
individuals (that will be performed in practice
between collaborative Holders).
*5) In Section 15.3. Unlinkability and Reusability of Status Assertions,
the text states:*
This design is pivotal in ensuring unlinkability between Verifiers,
where actions taken by one Verifier
cannot be correlated or linked to actions taken by another.
This sentence sounds strange. An "action taken by one Verifier" will be
invisible to another Verifier unless the network is unprotected,
but it is assumed that TLS is being used. What is the problem for
correlating "actions" taken by a Verifier ? This sentence would need to
be reconsidered.
However, "unlinkability between Verifiers" usually means unlinkability
between *colluding* Verifiers that shall not be able to know that a same
end-user
made an access to a protected resource.
Using SD-JWT, such property can be supported if a SD-JWT are used only
once. This should be mentioned in this section.
*6) An alternative method for the demonstration of the validity status
of a digital credential*
**
This alternative method has been constructed considering all the
components of the ecosystem and in particular the wallet,
as well as all the phases prior to the placement of one or more
credential in a wallet.
A Holder SHALL NOT be an application executed in an insecure environment.
The typical use case is an application executed by a Trusted OS which is
supported by a TEE (Trusted Execution Environment).
Asking one-by-one for the revocation of credentials takes time and is
not "user friendly".
Instead of using the Status Assertion mechanism to revoke a credential
placed in a wallet, it is possible to suspend either
the use of one credential placed in a wallet or, much better, *to
suspend at once the use **of all the credentials placed in a wallet*.
In case of a panic, it is much better to first *suspend* all the
credentials placed in a wallet and then to think more about what to do.
If, later on, the wallet is found again, then all the credentials placed
in the wallet can immediately be reactivated at the same time.
The Status Assertion mechanism is unable to accomplish this performance.
Two cases need to be considered:
* the wallet is used in an online environment where the Verifier is
accessed by the Holder using the Internet, or
* the wallet is used in a local environment where it is not connected
to the Internet.
In the first case, this alternative method prevents the use of the
wallet in the *few seconds* following the demand from the individual
to suspend the use of the wallet. The Status Assertion mechanism is
unable to accomplish this performance.
In the second case, the wallet can continue to be used during a lapse of
time of approximately 24 hours ... unless a connection of the wallet to
the Internet happens.
If no connection to the Internet happens during 24 hours then the
performance will be identical to the case of the Status Assertion
mechanism but if a connection occurs
the performance will be much better.
In terms of security as well as in terms of ease of use for the
individuals, this approach is superior to the Status Assertion mechanism.
The "magic" of this alternative mechanism is rather simple. While many
variations of it are possible the goal of this email
is not to make a detailed description of them.
However, the idea is the following:
1) When the smart phone connects to the Internet, at any time, the
provider of the TEE can inform the Holder (application)
that it shall suspend the use of all the credentials. Later on,
the provider of the TEEcan inform the Holder (application)
that it shall delete the credentials.
2) As long as the smart phone is NOT connected to the Internet, the
Holder (application) shall only allow the use of the credentials
during 24 hours.
This method does not require the use of any structure like a Status
Assertion but requires the development of a protocol between the Holder
(application) and the provider of the TEE.
Finally, this method offers the major advantage of allowing the
development of Trusted Holder applications that *can be resistant to
collaborative attacks between individuals*,
in particular when a selective disclosure of claims is being used.
Denis
Hello Everybody,
OAuth Status Assertions replaces OAuth Status Attestations and it is
published here:
https://datatracker.ietf.org/doc/draft-demarco-oauth-status-assertions/
Therefore here its html preview:
https://www.ietf.org/archive/id/draft-demarco-oauth-status-assertions-00.html
Compared to the previous draft, the change in the draft name reflects
the feedback received on the mailing list, for which I am very grateful.
The work continues and tomorrow there will be an engaging discussion
about the new drafts concerning revocations, including status assertions,
status lists, and OAuth global token revocation, during the OAuth
interim meeting.
From my understanding, there are several use cases for revocations,
each of which is addressed, either wholly or partially, in these
specifications.
It makes sense to think that different specifications satisfy
different use cases, it is important to understand in which cases
which technologies are ideal.
It appears that we have reached this understanding. Or, at least I
hope so.
For any additional feedback, please share; the authors and I will
ensure nothing is overlooked.
best
Giuseppe
Il giorno mer 17 gen 2024 alle ore 19:07 Orie Steele
<orie@transmute.industries> ha scritto:
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 STEELEChief Technology Officerwww.transmute.industries
<https://transmute.industries>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
