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 <demarco...@gmail.com> 于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 > <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 STEELE >> Chief Technology Officer >> www.transmute.industries >> >> <https://transmute.industries> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > -- > SPICE mailing list -- sp...@ietf.org > To unsubscribe send an email to spice-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
