Hi Giuseppe,
I missed this
> IMO, neither the "Token Status List", nor to the "OAuth Status
Attestations" are the right way to address two privacy considerations:
"Unlinkability between verifiers" and "Untrackability by digital
credential issuers".
here my notes
*Unlinkability between
I missed this
> IMO, neither the "Token Status List", nor to the "OAuth Status
Attestations" are the right way to address two privacy considerations:
"Unlinkability between verifiers" and "Untrackability by digital credential
issuers".
here my notes
*Unlinkability between verifiers*
Status
Ciao Denis,
I agree with you until I find that the presentation/credential format has
the feature to attest its (non-)revocation. I was a BLS signature
evangelist at least two years ago. Working in the government field, I am
now required to use formats that are globally recognized and
Hi Giuseppe,
We are on different tracks.
There is however a common point in our two approaches: "however, we
assume that the Wallet Instance had an internet connection within the
last 24h".
However, there is no need to present an "OAuth Status Attestation" to a
verifier.
IMO, neither the
Ciao Denis,
OAuth Status Attestation was born because of some different approches with
the oauth status list token, I really would like to have a single
specification with the two approaches.
I report below and explain the main differences between the status
attestation and the status list token.
Hi Guiseppe,
In your reply, you cut the main content of my original text and hence
you didn't reply to it.
In addition, you missed to pay attention to the email I sent yesterday
in my response to "I-D Action: draft-ietf-oauth-status-list-01.txt".
I copy some parts of it below:
Another
Hi Tom,
I know that many standards editors are tasked to solve actual real life use
cases but the existing standards do not suffice their requirements. Writing
good standards is hard work and I think people usually don't do it without real
needs.
18 Jan 2024 18:44:08 Tom Jones :
>
> The big
> *Inviato:* giovedì 18 gennaio 2024 18:43
> *A:* Denis
> *Cc:* demarcog83 ; hannes.tschofenig=
> 40gmx....@dmarc.ietf.org ;
> sp...@ietf.org ; Francesco Antonio Marino <
> fa.mar...@ipzs.it>; Giuseppe De Marco ;
> oauth
> *Oggetto:* Re: [OAUTH-WG] [SPICE] OAuth Digi
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
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
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
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:
I think both Pauls and Giuseppes approches are needed and should
progress in the IETF.
Cheers Leif
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
13 matches
Mail list logo
