Re: AS2/AP tasks for a chartered social web working group

po 18. 9. 2023 v 16:40 odesílatel Bumblefudge von CASA <
virtualofficehours@gmail.com> napsal:

>
> On 18/09/2023 16:33, Melvin Carvalho wrote:
>
>
>
> po 18. 9. 2023 v 11:55 odesílatel Bumblefudge von CASA <
> virtualofficehours@gmail.com> napsal:
>
>> On 16/09/2023 01:51, Bob Wyman wrote:
>> > For instance, it might include things like "secure private messaging,"
>> > "integration of verifiable credentials," etc. rather than identifying
>> > errors in spec examples.
>>
>> On 17/09/2023 17:31, Melvin Carvalho wrote:
>> > I think the "identity" folks will look to insert new identity systems,
>> > this should be out of scope.  Getting the existing Actor model working
>> > and documented should be priority.  Out of scope for the charter DID /
>> > VC.
>> Melvin, are you calling Bob one of "the identity folks" whose toxic
>> technosolutionism you want to protect AP from because he wants to
>> include key-management problems in the CG's to-do list? I've met him and
>> I think he is far too sensible to self-identity as a rabblerouser in the
>> populist identity Volkstimme. Conversely, are you requesting that we put
>> interop with key-based identity systems (like Nostr), E2EE, and
>> data-signing/data-integrity completely out of scope as problem spaces,
>> or just that the specific word "DID" be barred from the corresponding
>> set of solutions to consider for each?
>>
>
> Absolutely, DID is out of scope. Tantek has highlighted valid concerns
> with the DID work, and formally objected to it. Given his role as a former
> chair of the SWWG, his insights are valuable. Looking back, I should have
> supported his viewpoint. Please consider this message a formal objection to
> including DID-related identity items in any future social web charter. It
> risks jeopardizing the success of a WG. Let's focus on activitypub,
> fediverse, and the current Actor models.
>
> To be frank, it's not that I want DIDs in-scope, it's that I am asking for
> a technically precise and procedurally valid way of putting them OUT of
> scope if, for example, interop with Bluesky and Nostr is targeted, or for
> that matter E2EE.  Perhaps *all* external interop and *all* key
> management/E2EE should stay in the domain of the incubation CG?  That suits
> me just fine, as I only think DIDs are worth discussing in the context of
> E2EE or interop with key-based systems (I personally prefer both topics
> stay in-scope for FEPs and out of WG scope, if a WG is chartered).
>

Regarding nostr, interop is already achieved.  Both through bridges and the
FEP system.  Interactions to and from the fediverse are seamless from my
POV.  Nostr has its own standardization tracks, based on open source
patterns.  I mention it because, depending on who you speak to, Nostr is
already part of the functioning fediverse.  Whether the WG wants to look at
bridges, is up to the WG.


>
>
>>
>> Similarly, in your other message about Evan's OAuth profile proposal,
>> you bring the valuable historical opinion that OAuth underdelivered for
>> the Solid community, and I have to ask a similar question: can we
>> document an OAuth profile as a extension or an interop profile without
>> bringing AuthN into the scope of AP itself and without making OAuth the
>> mandated solution to AP's AuthN needs? In my opinion we should *neither*
>> mandate indieauth *nor* mandate OAuth, but I'm happy if this CG can
>> document both and provide guidance and actionable interop profiles for
>> both to assist implementors who select either technology quickly get
>> federating and interoping with everyone else who made the same choice.
>> AuthN is one of the most daunting industry-wide problemsets and no
>> system as complex as AP is really "accessible" to any but the most elite
>> devs if they have to grope blindly in the authN trenches without an
>> interop profile.  Having multiple AuthN profiles to read before deciding
>> which empire to join would also be an unalloyed good for implementers, I
>> believe.
>>
>> Overall, I feel like we need to be precise about what is a documentation
>> of already-adopted practice, which supports communities of
>> implementations, versus what is mandating single solutions to general
>> problems (like AuthN or key management).  In W3C, the former is
>> traditionally the domain of CGs, and the latter is traditionally the
>> domain of WGs, which might explain lots of the knee-jerk responses to a
>> WG charter being scoped in the first place.  There might already be
>> consensus that more of the former is an unalloyed good, but the latter
>> seems harder to achieve consensus on until the problem-spaces are better
>> defined (in this I fully support Bob's suggestion that maybe socialhub
>> threads are not quite robust or multidimensional *enough* a genre for
>> shared documentation of use-cases and problem spaces to assist in a WG
>> scope being defined).
>>
>> Thanks,
>> __bumble "I have an identity.com sticker on my laptop" fudge
>>
>>