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 standardized (please don't delve into this; I mentioned it just to be honest with you).
According to this awareness, we, along with other authors and implementers, need a revocation checking mechanism that is agnostic to the format and scope of the subject to which the status is attested and completely privacy preserving. Both Status Lists and Status Attestations are suitable for different use cases and solve specific problems. That's why they exist, taking into account the design principle of being agnostic to the subject format. Merging them into a single draft would be the ideal solution. However, if this is not possible and at the same time people require an OCSP stapling-like approach, OAuth Status Attestations are justified in their existence. I took your notes: - todo: privacy considerations section - A policy identifier included in a digital credential would indicate that this digital credential, when stored in a wallet, is still under the control of its digital credential issuer. I'll put my hands on the specs before IETF in brisbane (asap). If you're interested in improving this brand-new specification and considering how you might implement it, any contribution from your side is appreciated and will be taken into account, both now and in the future. To ensure your contributions are not lost in email threads, please consider opening issues here: https://github.com/peppelinux/draft-demarco-oauth-status-attestations/issues I just open several issue to keep track of your hints, thank you Denis! Il giorno mer 7 feb 2024 alle ore 12:12 Denis <denis.i...@free.fr> ha scritto: > 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 "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". > > Anyway, none of these two approaches would be usable with digital > credentials signed using BBS+. > A single solution able to work in all cases would be preferable. > > It can be supported by including an additional field in a digital > credential: a policy identifier. > > A policy identifier included in a digital credential would indicate that > this digital credential, when stored in a wallet, is still under the > control of its digital credential issuer. > > An I-D would be necessary (and sufficient) to define such policy > identifier. > > Denis > > 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. > > Taken from status list editor's copy draft > > This (Status List Token) allows for the Status List Token to be hosted > by third parties or be transferred for offline use cases. > > it is not clear how: > > - the token is rquested and obtained and used > - why it would be hosted by a third party > - the meaning of "transferred" > > AFAIK this token reference a status list, with url and index, allowing a > RP to control over time the status of a credential. > It is not clear the scope of this token, in my assumption it represent a > long lived attestation of the historical status of a credential and that's > fine, but doesn't protect user privacy against revocation status checks > over time by unallowed RP. > > Here the summary of the razionale behind OAuth Status Attestation > > Use Case Scenario: > - A Verifier needs to check the status of a given Credential only during > the presentation flow. > - A Verifier is not allowed to check the status of a Credential over time > (after it was presented by the Holder), due to some privacy constraints. > - No internet connection is available during the presentation phase > (however, we assume that the Wallet Instance had an internet connection > within the last 24h). > > The idea: > The Credential Issuer provides the Wallet Instance with a Status > Attestation, which is bound to a Digital Credential. This allows the > Wallet Instance to present it, along with the Digital Credential itself, to > a Verifier as proof of the Digital Credential's non-revocation. > > Merging the two approaches or extending OAuth Status List with OAuth > Status Attestations is always possibile if the authors wants do this, I > want do this if resonable to you and the WG as well, > best > > > > > Il giorno mer 7 feb 2024 alle ore 09:03 Denis <denis.i...@free.fr> ha > scritto: > >> 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 approach would be to consider that it is not the job of the >> verifiers to check the “non-revoked” status of the digital credentials they >> verify, >> but that it is the job of the Holder (application). This would be a >> “Holder centric” approach. >> >> The Holder (application) needs to be a Trusted Application (TA) that can >> be trusted by the digital credential issuer to effectively control >> and limit the use of some cryptographic keys and that cannot be modified >> by an individual. A “digital identity wallet” is the prime example of a TA. >> >> In the real-life, a “*digital identity wallet*” is supported by a smart >> phone or a tablet which will usually be online as soon as some network is >> locally available. >> >> When a digital credential is requested by a Holder at the initiative of >> an individual, the base URL of the digital credential issuer needs to be >> provided. >> Such base URL can be built-in the downloaded Holder (application), added >> when a revision of that Holder (application) is available or manually >> entered by the individual. >> >> An access point to contact the digital credential issuer can be derived >> from the base URL of the digital credential issuer. >> Once a digital credential has successfully been downloaded by the Holder, >> this access point can be used by the Holder to dialogue with the digital >> credential issuer >> as soon as the smart phone or tablet is online. >> >> During this dialogue, if some entity asked to a digital credential issuer >> the revocation or the suspension of a digital credential still within its >> validity period, >> the digital credential issuer can freeze (i.e. suspend) the use of that >> digital credential. A policy may be put in place to say that if no contact >> has been possible >> with a digital credential issuer during some period of time, the use of >> each digital credential issued by that digital credential issuer will be >> frozen by the Holder. >> As a consequence, *if a digital credential has been able to be used by a >> Holder, this means that it has not been frozen*. >> A digital credential can later be unfrozen by its digital credential >> issuer. >> >> If there is a desire to freeze all the digital credentials stored in an >> app, the TA Manager of that app would be in a position to do that. >> >> In the context of the “Issuer-Holder-Verifier model”, the above >> descriptions are sketches of possible approaches that highlight the fact >> that, >> the "Token Status List" approach might not be the best way, nor the >> simplest way, to support the two following privacy properties: >> “Unlinkability between verifiers“ and “Untrackability by digital >> credential issuers”. >> >> Theses approaches are alternatives to >> draft-demarco-status-attestations-01 and to the "Token Status List" >> approach that would be simpler to implement. >> >> Also note that, at the moment, draft-demarco-status-attestations-01 does >> not contain a "Privacy considerations" section. >> >> >> Denis >> >> Hi Denis, >> >> sorry for the delay, below by points. >> >> > A *digital credential* may be presented to a verifier long after it >> has been issued. >> >> In the abstract we say what's the status attestation. Probably it's an >> editorial suggestion from you to say what's the substantial difference >> between the digital credential and its status attestation. the subject of >> this specification is the status attestation, not the digital credential >> which the status attestation is referred to. >> >> > Entity that relies on the validity of the *digital proof* presented to >> it. >> >> verifiers validate the digital credentials and these can have different >> revocation check mechanisms (or no one). I'd keep the digital credential as >> the most important landmark for the verifier, where the status attestation >> is a sort of annex of that. >> >> > This does not correspond to the flows of the figure. >> >> The picture contains two distinc moments: the provisioning of the >> attestation (that currently in the specs is online only) and the >> presentation of it (that works fine in the offline scenario). >> >> I'll look forward for other interactions about this specs, probably by >> voice it would be everything more easy to explain, >> thank you for the hints! >> best >> >> >> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
