MIME-Version: 1.0
References: <8A26654C-0779-4170-BC64-29698042AC49@icloud.com>
 <2CC43BE3-762D-45C5-BBF9-B2A70E5D8CA9@brandedcode.com>
In-Reply-To: <2CC43BE3-762D-45C5-BBF9-B2A70E5D8CA9@brandedcode.com>
From: Willem Dantuma <willem.dantuma@dobs.nl>
Date: Wed, 3 Dec 2025 08:03:55 +0100
Message-ID: 
 <CACOhus5Fzxh8BcpB=Nu2wEhG8vZVDt50APdvWLiGcJWWiGE5Gg@mail.gmail.com>
To: Bryan Newbold <bryan=40blueskyweb.xyz@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007e407f064506d1a5"
Message-ID-Hash: OZMJVXL7QMOTZXQAVCMHSF2SJB5ABF7U
CC: Meredith Espinosa <b0undarybreaker=40icloud.com@dmarc.ietf.org>,
 atp@ietf.org, emelia <emelia=40brandedcode.com@dmarc.ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BAtp=5D_Re=3A_Adding_Identity/Auth_to_Charter?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/atp/FZKErO2NX_kkMRfg1jgA_7aP3RI>

--0000000000007e407f064506d1a5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=3D
40brandedcode.com@dmarc.ietf.org>:

> 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 i=
t
> 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) fundin=
g
> so I can spend the time on it.
>
> Emelia
>
> On 3. Dec 2025, at 03:15, Meredith Espinosa <b0undarybreaker=3D
> 40icloud.com@dmarc.ietf.org> wrote:
>
> =EF=BB=BFI'm in favor of DIDs being generically mentioned without definin=
g
> 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=E2=80=AFPM, Bryan Newbold <bryan=3D
> 40blueskyweb.xyz@dmarc.ietf.org> 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 feel=
s
> like.
>
> Instead of abstractly describing the requirements for a persistent accoun=
t
> identifier, we could just say that W3C DIDs are the framework: DIDs are t=
he
> 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 no=
t
> (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. T=
he
> 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 discussio=
n.
>
> --bryan
>
> [0]: https://datatracker.ietf.org/doc/draft-ietf-dnsop-integration/
> _______________________________________________
> Atp mailing list -- atp@ietf.org
> To unsubscribe send an email to atp-leave@ietf.org
>
>
> _______________________________________________
> Atp mailing list -- atp@ietf.org
> To unsubscribe send an email to atp-leave@ietf.org
>
> _______________________________________________
> Atp mailing list -- atp@ietf.org
> To unsubscribe send an email to atp-leave@ietf.org
>

--0000000000007e407f064506d1a5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Describing the desired properties for a DID method would b=
e indeed a way to limit somewhat the possible identifiers, otherwise i&#39;=
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 unusab=
le ( not interoperable ).<div><br></div><div>The same goes for handle resol=
ution I guess<br><div><br></div><div>I would like to prevent that a library=
 implementer needs a third party service ( like universal resolver ) to do =
the DID resolution for them=C2=A0<br><div><br></div><div>Willem</div></div>=
</div></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=
=3D"ltr" class=3D"gmail_attr">Op wo 3 dec 2025 om 03:29 schreef emelia &lt;=
emelia=3D<a href=3D"mailto:40brandedcode.com@dmarc.ietf.org">40brandedcode.=
com@dmarc.ietf.org</a>&gt;:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"auto">This all sounds good to me. I&#39;m going to =
see soon about what&#39;s required for writing a draft OAuth Profile for de=
centralized social web, because it is very necessary.<div><br></div><div>As=
 for DIDs, perhaps it&#39;d be better to define the desired properties for =
the DID Method to be compatible, rather than naming specific methods?</div>=
<div><br></div><div>Handle to DID resolutions sound good to include. Maybe =
changing http resolutions to use like /.well-known/handle as a small json d=
ocument that has keys of protocols (registry) mapped to DIDs?</div><div><br=
></div><div>The only big asterisk on the OAuth Profile is a) never done if,=
 b) funding so I can spend the time on it.</div><div><br></div><div><div di=
r=3D"ltr">Emelia</div><div dir=3D"ltr"><br><blockquote type=3D"cite">On 3. =
Dec 2025, at 03:15, Meredith Espinosa &lt;b0undarybreaker=3D<a href=3D"mail=
to:40icloud.com@dmarc.ietf.org" target=3D"_blank">40icloud.com@dmarc.ietf.o=
rg</a>&gt; wrote:<br><br></blockquote></div><blockquote type=3D"cite"><div =
dir=3D"ltr">=EF=BB=BFI&#39;m in favor of DIDs being generically mentioned w=
ithout defining specific methods used - did:plc is not yet standard and to =
my knowledge people are still researching and considering other potential I=
D systems beyond the PLC.=C2=A0<div><br></div><div>As for handles, I feel l=
ike both DNS TXT and HTTPS .well-known are common and easy enough that they=
 can be included without too much trouble.<br id=3D"m_-3175513323991744830l=
ineBreakAtBeginningOfMessage"><div><br><blockquote type=3D"cite"><div>On De=
c 2, 2025, at 5:54=E2=80=AFPM, Bryan Newbold &lt;bryan=3D<a href=3D"mailto:=
40blueskyweb.xyz@dmarc.ietf.org" target=3D"_blank">40blueskyweb.xyz@dmarc.i=
etf.org</a>&gt; wrote:</div><br><div><div dir=3D"ltr">We&#39;ve received fe=
edback from a number of folks that the initial charter scope should cover m=
ore about network identity to be meaningfully interoperable. I want to expl=
ore that direction a bit to see what it feels like.<div><br></div><div>Inst=
ead of abstractly describing the requirements for a persistent account iden=
tifier, we could just say that W3C DIDs are the framework: DIDs are the ide=
ntifiers, and DID documents contain the required account data (keys, identi=
fiers, 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.</div><div><br></div><div>I think specifying an e=
xact set of DID methods in a formal IETF specification would be hard, becau=
se 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 o=
r any other venue. It could take time to get those gears turning, on a time=
line outside of this group&#39;s control. The ATP working group could publi=
sh a less formal BCP describing current recommendations (&quot;use did:plc =
and did:web&quot;)? Or find some other way to discuss and nudge in this dir=
ection. Alternatively we could just say that DIDs are the abstraction bound=
ary for the scope of the working group, and leave it at that for now.</div>=
<div><br></div><div>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, thoug=
h 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 DNS=
OP about the AT use-case [0], and there are some other relevant drafts unde=
r discussion.</div><div><br></div><div>--bryan</div><div><br></div><div>[0]=
:=C2=A0<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-dnsop-integra=
tion/" target=3D"_blank">https://datatracker.ietf.org/doc/draft-ietf-dnsop-=
integration/</a></div></div>
_______________________________________________<br>Atp mailing list -- <a h=
ref=3D"mailto:atp@ietf.org" target=3D"_blank">atp@ietf.org</a><br>To unsubs=
cribe send an email to <a href=3D"mailto:atp-leave@ietf.org" target=3D"_bla=
nk">atp-leave@ietf.org</a><br></div></blockquote></div><br></div><span>____=
___________________________________________</span><br><span>Atp mailing lis=
t -- <a href=3D"mailto:atp@ietf.org" target=3D"_blank">atp@ietf.org</a></sp=
an><br><span>To unsubscribe send an email to <a href=3D"mailto:atp-leave@ie=
tf.org" target=3D"_blank">atp-leave@ietf.org</a></span><br></div></blockquo=
te></div></div>_______________________________________________<br>
Atp mailing list -- <a href=3D"mailto:atp@ietf.org" target=3D"_blank">atp@i=
etf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:atp-leave@ietf.org" targe=
t=3D"_blank">atp-leave@ietf.org</a><br>
</blockquote></div>

--0000000000007e407f064506d1a5--