# Running Agenda & Minutes of Distributed Data Storage & Relay Implementer Calls

[ [DIF Calendar](https://bit.ly/dif-calendar) | [spec](https://github.com/decentralized-identity/identity-hub/) | [zoom link](https://us02web.zoom.us/j/83661706904?pwd=Z2MxNWJJalVGbXNNRTdGRC9HeTNEZz09) ] meetings every other Wednesday at 7

## 2021-07-15 - Hubs update

Daniel
- overview - 3 architectures that might be aligned/abstracted
+ "everything is a filepath"
+ URL routes (REST based)
+ Object-Oriented (DIDComm-esque OO protocol)
+ design goals
+ DID URLs - *encode* the passage of an object
+ Adrian: could even be a token, no? Daniel: Yes
+ various approaches to "normalization" of interfaces
+ "permission objects" and invocations
+ combine/embed api command objects and capability invocation
+ adrian: AuthZ choices, can we separate those concerns (addressing and authorization)
+ Daniel: there needs to be some way of passing authZ signatures whatever the configuration; "the hub" would enforce policies and
+ Daniel: could work across diff architectures (say, microservices); but all this works as a logical whole regardless, by dint of the hub abstract itself
+ adrian: end-user managing agents and hubs distinctly? Daniel: I don't think the hub should care;
+ Adrian: Inrupt/solid seems to collapse the agent and hub; is there a standardized API between hub and agent
+ daniel - proposals
+ Hub's native language = object-based; anything higher-order must be translated
+ dereferencing pretty standards, service=identityhub in a DID URL that looks like example 1 [here](https://w3c-ccg.github.io/did-resolution/#dereferencing-algorithm-primary)
+ Adrian: Service Endpoint survey in DIF Glossary group a yearish ago: mediator function? //notification and //files/EDV

- Making that translation/abstraction more concrete
- filepath example:
- schema originals, illegal characters, other constraints?
- a recent fission PR: schema path translated to something non-inferential
- each company is responsible for that translation
- each approach brings certain constraints;
- Charles: I can sympathize with the "object"-abstraction approach; how would ZCaps work here?
- Daniel: UCanns gets passed, but not bound to the data, have to be passed along; what values *need* to be present in the objects for them to be translatable to all
- where ambiguous or requiring, say, an extra envelope or something, that can be specified by the object spec
- Charles: how work with CIDs?
- Read/write whatever corresponds to this CID? or more like
- Daniel: They're more like functions than invocations: the object contain a predicate and an action
- Abstracting the nature of the calls
- trying not to bind the objects to HTTP syntax/verbs, or at least a superset of them?
- Juan: how diff from JSONRPC?
- Adrian: Reminds me of RAR - Brian's recent email:
- https://medium.com/oauth-2/rich-oauth-2-0-authorization-requests-87870e263ecb
- https://pt.slideshare.net/TorstenLodderstedt/rich-authorization-requests
- https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar
- https://youtu.be/g_aVPdwBTfw?t=1240
- Adrian: layered control - does this specify/ossify a fixed set of options for backing systems?

- Daniel: Next steps
- a PR to better describe properties of the objects
- Juan: I'd like to see an example or two from each category of objects (Fetch, COllection-style, etc), ideally with a simple use-case, for translating into the various backing architectures to have a concrete example to play with (and help identify corner-cases/limits to translation early...)
- working on a prototype in a branch /reference/, node server but works on client side (dexy) - not performant, but useful for testing and tire-kicking (JOSE-CBOR)
- reference might be useful to make service conversation a little less speculative and more concrete

## 2021-07-07 - Functional Requirements meeting

Hacky "Doodle" for new time proposal:

X = all of us could make this time

/ = some of us could make this time and/or we hate it

|time|daniel b|spruce|fission|ceramic|textile|
|---|---|---|---|---|---|
|Mon 18CET/9PST||X||||
|Mon 19CET/10PST||X||||
|Tue 18CET/9PST||X||||
|Tue 19CET/10PST||X||||
|Wed 18CET/9PST||X||||
|Wed 19CET/10PST||X||||
|Thu 18CET/9PST||X||||
|Thu 19CET/10PST||X||||

## Homework for 2021-07-07 - notes from various meetings and conversations

Boris (Fission): what are the "verbs" that define the core APIs and interfaces?

### Minimal Starting Point?

[#76](https://github.com/decentralized-identity/identity-hub/issues/76)

Sync strategies?

Wayne:
- Noise protocol?
- More web2 style?
- meta syncing

e.g. IPFS pinset?

Map content to paths?

Joel:
- Sync strategy at API layer?
- Where is the boundary layer? Can you use a server to do this?
- don't we immediately hit issues with encryption

Ted:
- encrypted blobs are going to be small or monolothic
- public read is FTP, do we need that?

Adrian Gropper
- relationship to EDV, auth, messaging
- more that we talk about ontologies -- this is not the space to do that

### Naming

[#75](https://github.com/decentralized-identity/identity-hub/issues/75)

Distributed Data Storage & Relay

Identity Hub --> Joel likes this name; pointed out by Boris that Identity is a trigger word

Distributed App Storage & Relay? --> app has baggage

Either about identity attached, or not

### IPLD Open Questions

Brooke: list open questions for IPLD team https://hackmd.io/G9mGFW_2QxuU3UMR1qjTzA

e.g. not providing data?
encryption scheme in the CID?
make it a triple?

### Administrivia

Can Boris get access to repo to help manage? Yes, Daniel can help make it happen

Everyone -- review issues!

---

Joel got from last call the sense that the functional reqs are:
1.
2.
3.

Adrian Gropper
1. The Identity Hub receives requests that result in scoped authorizations to be enforced in a domain (legal entity) separate from the domain of the Hub. [AG]
2. The Identity Hub (domain) and the resource server (domain) must both understand the authorization scope schema. The client (requesting party) "may" understand the schema but it's optional. [AG]
3. DIDs are relevant to the Hub but not typically relevant to the Resource Server (S). The relationship between RS and data subject DID is a separate "registration" flow that is ut of scope for the Hub specification. [AG]

Charles thinks they are...
1. Hub controller(s) can issue attenuated delegations to control access on hub resources
2. authorized invokers can perform capability-specified actions on hub resources
3. cryptographic DAG structures are preferable for various security and utility reasons

Brooklyn: Permissioning uses cryptree for read-access, UCann and/or cryptree for write-access; KMS gets a little more complicated; my open questions are more around interop between systems or about user-controlled storage.
- Fission was made very much for a serverless, dApp use case
- Daniel: but availability and throughput are a necessity for scaling this (phone can't be a hub alone)

Use-cases that break this model:
-

## 2021-06-23 - Use Cases

Use-case gathering

- Adrian: User-centric please

- Adrian: I'm trying to identify the authZ assumptions- cross-domain AuthZ when token for AS is given by Alice
- Daniel: Alice is Alice's AuthZ capability issuer
- Daniel: Borgcube replication & sync assumption

- Daniel: Playlist use-case
- Spotify shouldn't be asking for FHIR objects, for example
- (How's that communicated, tho?)

- Daniel: Hotel Use case (travel plan that can be synced across hotel chains)
- Adrian: but how is this attenuated? How is this scoped?
- Daniel: Granular resource sharing (no idea how that looks at UX layer)

Functional Requirements
- Daniel: "Request data by data"
- normalize data requests, discourage application/domain-specific apis or practices
- Daniel:"use SCHEMA.ORG as scopes"
- need to be JSON (to translate to DAG-JOSE)
- unique strings that map to data (don't typecheck)
- POD landscape might validate schemas, no idea how that works if encrypted
- validation (and data shape and transformation) on the consuming side, not at this layer

- Daniel: DID-relative URL
- DID needs to be changeable; can't be a URI in static sense

- Carson: Is ALICE always [inter]active in these AuthZs? Or is she one-time delegating hubs to a policy server or PEP?
- Daniel: its a policy choice, users/consumers could prefer that (but personally would not advise)
- Carson: if an application works this way, can e.g. spotify be one-time delegated a reusable authz to perform many actions for a goal? (e.g. data processing for recommendations)
- Daniel: Action inbox // FISSION's UCann (a capability??)
- Carson: Anything OCap-based or -like should be functionally equiv for my question, so sounds like... maybe?
- Daniel: the policy defn can be flexible enough that the hub doesnt have to care how most apps work to serve them
- Adrian: Protocol should be aware of when it's talking to Alice and when talking to a PEP she has delegated (and maybe act differently or process the data differently depending?). I would call that ATTENUATED DELEGATION FULL STOP.
- Daniel: But I think DID gives us that already? Adrian: No, a DID just gives you a service endpoint;
- D: a DID A can include a key in their DID Doc which is controlled by another party B, with an attestation that the key/verification methods authority has been delegated to B
- Daniel: Hubs could handle delegation many diff ways
-