[Atp] Re: Adding Identity/Auth to Charter

[Willem Dantuma <[e-mail]>]

Describing the desired properties for a DID method would be indeed a way to
limit somewhat the possible identifiers, otherwise i'am afraid we end up
with every ID issuer inventing its own DID method ( is already happening )
and we end with something similar to did web but unusable ( not
interoperable ).

The same goes for handle resolution I guess

I would like to prevent that a library implementer needs a third party
service ( like universal resolver ) to do the DID resolution for them

Willem

Op wo 3 dec 2025 om 03:29 schreef emelia <emelia=
[e-mail]>:

> This all sounds good to me. I'm going to see soon about what's required
> for writing a draft OAuth Profile for decentralized social web, because it
> is very necessary.
>
> As for DIDs, perhaps it'd be better to define the desired properties for
> the DID Method to be compatible, rather than naming specific methods?
>
> Handle to DID resolutions sound good to include. Maybe changing http
> resolutions to use like /.well-known/handle as a small json document that
> has keys of protocols (registry) mapped to DIDs?
>
> The only big asterisk on the OAuth Profile is a) never done if, b) funding
> so I can spend the time on it.
>
> Emelia
>
> On 3. Dec 2025, at 03:15, Meredith Espinosa <b0undarybreaker=
> [e-mail]> wrote:
>
> I'm in favor of DIDs being generically mentioned without defining
> specific methods used - did:plc is not yet standard and to my knowledge
> people are still researching and considering other potential ID systems
> beyond the PLC.
>
> As for handles, I feel like both DNS TXT and HTTPS .well-known are common
> and easy enough that they can be included without too much trouble.
>
> On Dec 2, 2025, at 5:54 PM, Bryan Newbold <bryan=
> [e-mail]> wrote:
>
> We've received feedback from a number of folks that the initial charter
> scope should cover more about network identity to be meaningfully
> interoperable. I want to explore that direction a bit to see what it feels
> like.
>
> Instead of abstractly describing the requirements for a persistent account
> identifier, we could just say that W3C DIDs are the framework: DIDs are the
> identifiers, and DID documents contain the required account data (keys,
> identifiers, service locations). The working group would either directly
> specify the data required to interoperate with AT, or liaise with another
> venue if that was more appropriate.
>
> I think specifying an exact set of DID methods in a formal IETF
> specification would be hard, because most of the relevant methods have not
> (yet) been formally standardized. did:plc is open to standardization, but
> has not been submitted to the W3C or any other venue. It could take time to
> get those gears turning, on a timeline outside of this group's control. The
> ATP working group could publish a less formal BCP describing current
> recommendations ("use did:plc and did:web")? Or find some other way to
> discuss and nudge in this direction. Alternatively we could just say that
> DIDs are the abstraction boundary for the scope of the working group, and
> leave it at that for now.
>
> Handles could also be added to the initial charter. The current AT handle
> system works with either DNS TXT records or HTTPS .well-known endpoint. I
> think this work could mostly be done within the WG, though we could also
> liaise and coordinate with DNSOP or other groups as needed. I am already
> co-author on a relevant informational-track IETF draft in DNSOP about the
> AT use-case [0], and there are some other relevant drafts under discussion.
>
> --bryan
>
> [0]: https://datatracker.ietf.org/doc/draft-ietf-dnsop-integration/
> _______________________________________________
> Atp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
> _______________________________________________
> Atp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> Atp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>