Thank you LanLan Pan, Orie is the (co-)author of both the specifications, therefore I would invite him to say something in this field. I heard about the Bloom filters and I can say that they should not be excluded from the analysis and comparisons (here Giada may say somethign more ...).
At this stage, due to the strict deadlines, I was unfortunately forced to use stable and well established mechanisms to satisfy the requirements, something that from my perspective seems quite good standing in the status assertions. Feedbacks are more than welcome, are needed! Il giorno mer 12 giu 2024 alle ore 11:45 Lanlan Pan <[email protected]> ha scritto: > Hi Giuseppe, > > 2.4.5. >> <https://www.ietf.org/archive/id/draft-steele-spice-oblivious-credential-state-00.html#section-2.4.5>Bloom >> Filters >> <https://www.ietf.org/archive/id/draft-steele-spice-oblivious-credential-state-00.html#name-bloom-filters> >> >> Appendix B.2.7 <https://rfc-editor.org/rfc/rfc8932#appendix-B.2.7> of [ >> RFC8932 >> <https://www.ietf.org/archive/id/draft-steele-spice-oblivious-credential-state-00.html#RFC8932> >> ] mentions an application of bloom filters, that can be applied to >> communicating credential state assuming the probabilistic nature of bloom >> filters is acceptable to the verifier. >> > > The verifier could verify credential signature to assure that the > credential content is correct. > Sometimes the verifier may verify the status assertion/attestation > signature to assure that the credential is available recently. > > Personally I think, bloom filter may cause false positive, which will > result the verifier in wrong decision. Verifier should avoid to use bloom > filter in the use case of credential verification. > > > Lanlan Pan > Giuseppe De Marco <[email protected]> 于2024年6月11日周二 05:59写道： > >> 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 >> <[email protected]> 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": "[email protected]", >>> "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://transmute.industries> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> -- >> SPICE mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
