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
>
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

Reply via email to