re: 0016 make getSpaceCredential more generic?

[michielbdejong]

First of all, I have to say I love this work! It's very elegant in how it solves some genuinely hard problems in decentralised authorization. It's light-weight in the right places. I love that the space authority is free to choose its own mechanism for making the access control decision, e.g. there is no coupling between that and space management mechanisms, and how it reuses existing #account and #identity event signals for migration.

One question though: the space credential section says getSpaceCredential takes a delegation token and optionally a client attestation.

You could add a third optional component there, with room for free-form claims. For instance, a verifiable credential proving some attributes about you, or a purchase receipt. And if this claim is present, the identity claim may be omitted. Unless I'm missing something, this would not be a big change, right? Spaces that require real identities from authors as well as from lurkers can still require the delegation tokens, while others get the option of gating based on coupons or whatever other criterion feels right for them.

[dholms]

Yeah I actually like this quite a bit. Maybe just another property on the input: claims which is an array of open unions? Or maybe even an array of unknowns?

[bnewbold]

I kind of feel like this should be punted up to an app/service level. If it is an open-ended extension point it isn't going to be super interoperable anyways.

For example, you could have a paid video lecture app. Authors would publish videos as atproto permissioned data. A pay-gating service would be given access to all the videos (via service account/identity). Viewers would present arbitrary auth info to the gating service as proof of payment (receipts, tokens, proofs, claims, etc) and then stream or download the video.

[michielbdejong]

Good point! I don't agree with the argument that other claim types can (paraphrasing) "just solve this with a custom access control server in front of the PDS"; that is something that is already available now to all claim types including handle-gating, and if that option were satisfactory then I think we wouldn't need this proposal in the first place? The fact that we want to solve it for handle-gating signals that it might be worth solving it more generically, for "anything-gating", and generic specs are better than specific ones.

I do realise handle-gating deserves a special place in this spec because all clients already know how to ask the user for their handle. There is only one way to do that and it's well-described and widely implemented in the Atmosphere. This means that no extra mechanics are needed on top of this spec to make handle-gating interoperable, whereas e.g. pay-gating would require something vaguely x402-shaped on top, etc.

So I do understand you want to design for the clean and easy "handle-gating" use case and leave the more complex use cases like pay-gating, membership-gating, age-gating, geo-gating, ... out of scope.

But IMHO saying handle-gating is the only allowed claim type would be unnecessarily restrictive, at the wrong spec layer. To me it would feel as if e.g. HTTP 1.1 had said http basic auth was the only allowed Authorization header. The HTTP spec allows any string-typed request and response headers for which it doesn't require or guarantee interoperability, it just offers a place where higher-level protocols can put their custom data. That's why so much open-ended innovation happens on top of HTTP.

You can give opaque claims a place in this spec without restricting what they should contain. The specific claims gathering for claims other than the user's handle happens at the UI level and the mechanism for transporting those claims from the client to the PDS can treat them as opaque, and pass the yes-or-no answer back to the application layer, no problem. Even at the application level there might be a claim=... string from e.g. a QR code which both the user and the application treat as an opaque string.

If you don't provide the expansion slot for opaque claims then those other use cases can't grow on top of this spec.

[michielbdejong]

Ah, and maybe redundantly, you can spec out the optional field for opaque claims without implementing its use in your own stack. Someone else could fork your PDS software to implement what they want to invent.

How the custom claim type is handed out, how it is checked, and how the opaque claim string travels e.g. inside a QR code, NFC, bluetooth, or whether the user types it into the UI, is all out of scope for this spec and maybe even for Atproto.

I think the only thing you need to open up is the arguments in getSpaceCredential.

[michielbdejong]

Viewers would present arbitrary auth info to the gating service as proof of payment (receipts, tokens, proofs, claims, etc) and then stream or download the video.

Ah, but a variation on that could be that the user authenticates when they cash in their voucher at the custom service, then the access is tied to their identity, and after that the rest is identity based. So access to the space is still ultimately gated inside the PDS instead of by a proxy in front of it, but it's preceded in time by a 'cash in your voucher' step. Maybe that is what you meant in the first place, sorry. :)

In that case there still is the issue of unnecessarily leaking PII but that's a smaller concern than my original one.