Secure Data Storage WG Agenda - Thurs June 3rd, 2021

Current Spec

Issues

Notes - Hubs Dedicated Call

Daniel: CrypTree is mentioned and there is a curiosity about how far the discussion went and Brooklyn who raised it isn’t in this meeting. Joel says: We didn’t talk about Cryptree that much we talked about encoding extra meta data along with CRD - doesn’t have enough knowledge to discuss today. Dan: Could work on a PR - in the next week and have that be an action item out of the call. Joel says he can get started on it tomorrow and what help. PR Discussion Feature Detection Interface - hubs can have different feature detection - account set up is quiryable by developers. Daniel walks through Hub Configuration possibilities Clarification Identity Hub is a service end point and not content addressable - if it was content addressable you couldn’t make a feature request in the same way. Daniel talks about sending objects message based - feature detection read - send it back to Q from Michael Herman: How does this "feature" stuff intersect with Verifiable Capability Authorizations/zcaps type of access control? A: Access portion is needed but not in spec yet - so we need to do that. Right now - type of data - public things. If you put this as your feature detection object you won’t have to worry about capabilities. Michael: One thing at top of one master verifiable capability authorization: https://hyperonomy.com/2021/04/26/the-verifiable-economy-architecture-reference-model-ve-arm-fdo/

As this develops you might want to weave these together. Dan: It is like feature detection in the web. Implicitly tell you what profile read map. Based on what is in the Hub. Brooklyn created a PR to make descriptors just a simple object. So that the index is the primary object. Question: How do you address things? Thoughts were :did:foo:123?service=identity-hub?interface=Profile&action=ProfileRead Do you query for data for CID - you would have to know. With this being DID relative helps you. Durable - will always work. Find service end point that is an identity hub. How would it work with a key did? You could have a key did that goes to a registry - that is where its end points are registered. Relied on service end points feature of DIDs. Anything that is more then just “a key” a lot of people in peer-to-peer community are just using key:did because of simplicity. Lots of different ways to address hubs. Cashable signed objects. Adrian: asks about authorization mechanism. Dan some objects don’t need authorization What type of authorization - capabilities or something signed by registered entity. OpenID is built on top of OAuth when they did openID on top of OAuth they introduced dynamic client registration. Because OAuth itself is based on shared secrets and registered client IDs. This is why the authorization discussion is happening now in the VC-HTTP-API group - is the thing that holding up the works . Adrian referencing Christopher Allens articulation of SSI saying Agency is one of the things and that it is the person’s right to delegate to an agent they choose a doctor, lawyer etc. The question is (After a decade) do you have to pre-register your client or not. HEART has failed and stalled out after 6 years. Client registration becomes a lot easier because you don’t need a shared secret the way OAuth does. Capabilities is brought up - and Adrian shares how much of a fan he is of them and thinks they are the right solution. We need to agree that it is not the only solution for delegation. If the goal is to enable agency on the part of the Self-sovereign subject then either the issuer or resource server - has to accept public key registered by subject - or issue capabilities that can be attenuated by the subject. Either can work - scope of hubs could be better if both were available. One require resource server keep separate public key for each resource owner or subject - different cost with capabilities (computational cost) I am in favor of doing both. Elaboration requested: Hub having key - when the client brings an authorization token to resource server the resource server has to trust the key that is signing the authorization token and there are two ways it can decide to trust the key - either it has pre-registered pre-stored the public key associated with signing key of the toke - or token is signed with their private key because they issued it to the resource owner in the past. GEtting a token reading its scope and getting that VC/playlist. Is it object based capability vs ACL. No neither is ACL. One case you have pre-registration by resource owner of the public key that will be used to sign the tokens. In the other case the resource owner just received the capability which can then delegate with our without attenuation. ACLs are also a good option here in addition to carried credentials. But no then you get into openID connect conversation. In general - all of these protocols end up with a token rather then an “identity” (unless jurisdictional issues). It is a separate role. Out of band from authorization role. The resource owner doesn’t have to have a DID at all you can assume that they al. Does the resource owner have to have a DID? NO but you can assume that they do if you want. Authentication is not the issue. When thinking about capability for an identity hub - root trust is DID of subject - can delegate to another user or to server that is hosting hub. Root Trust would need to rest in users DID. There is another option. EDVs have this notion of a Central or root capability. AT the heart of the Vault - stored in vault config or in Hub config - this is the DID of the resource controller. This is going back to earlier comment (Michael) where Daniel is showing that profile read thing at some point the capability authorization needs to be attached to and says who can do what. There needs to be a master capability authorization when it is birthed. Adrian says that he thinks Micheal is confusing scope - The object can be a presentation that is subject to filtering and to scoping and the capability has as scope - scope issue is very important but it is not attached to the object - if you have an identity hbe and it has 5 different kinds of object that make up 80% of what is there. Some will have different options for scoping options to the (FHIR data model) others will be simpler like banking objects - some will be trivial right to read/write or both. Objects want to manage with data models that want to be published by resource server. Thinking of capability as part Dan: Joel the way we have to deal with authorization layer. How do you authorize those recipients. Look at interfaces. Message based interfaces worth looking at. Can we live with it - it is a message thing so doens’t have to be bound to a protocol would be great if folks could develop opinions. Dan: goal for end of june - even if we don’t have authorization together - could put together a public data hub. Who bears the cost? Are they transport layer or message layer. The other issue is a business issue. Who bears the cost of processing these messages? If the root is a message from a client to the resource server first. Lets think about it as a wholistic thing. Lets just think about it all as one box. Hub is one box - who pays for the box doing its stuff. Who is going to pay for it? Users are going to pick third parties and going to run them. The host will bear the cost - free cost born by those hosts. Providers already do this. Adrian - you are jumping into the Solid Model where the authorization and resource server are co-located - operated by the same entity. There are a number of problems with that. One is that Vendor lockin is much more likely. You are also forced to make copies of data from a lab or whatever into the solid pod or identity hub storage layer - when all you really wanted for those people who use services - iot device - you want them just to be trusted to interact with your identity hub as an authorization server. If we are to add value treating them as authorization servers first here is the request that someone is making that I have to spend that money would not lump that with encrypted data vault or whatever the storage is - the fact we chose IPFS. I don’t think we have a data lockin because I’m going to fight hard for one formulation of identity hubs. Using that standar trad formulation two identity hubs will talk to each other and sync. Not picking MSFT or AWS. Adtrain - I agree with you. IPFS doesn’t have a delgatable authorization mechanism in front of the storage. So if you want to build on self-sovereign principles you want a standards based protocol in between the authorization server and the storage server. Solid goes in a different direction expecting people to bring their apps to the data. In effect running the authorization server not explicitly against having a standard authorization server or protocol for the storage component. They aren’t doing this Dan: Really hard for me to understand this. Hub will have the ability to affect authorization whether it runs on the same machine. The hub will have a standard thing for authorization and permissioning in the spec. Adrian: A client comes to the identity hub with a request - does the client get an object or does it get a token in return for that. What you are saying some hubs will issue you tokens and some hubs will give ou the object - is that what you said? What does client get back in message based system. Further request to create Not there yet. Get a response back Used as a associated with policy. Or being given authorization policy to give to the hub the next time - so that you know you have been authorized. Primarily based on DID. Post of new object - it is Bob. DID is granted access from Alice - it has got to be bob - ACL model has a lot of pushback. Holding Bobs DID - ACL is not in control - encrypted for Bob is going to see - hub only job to hand out objects to who they are supposed to. We will have to get Client just a client - bringing bobs claims - client makes a request - formatted - only thing that matters - token turned in somewhere or - given object to Bobs or bobs client. How tokenst are coded and signed and how scopes are standardized. W/o authorization - only public objects. Anyone who shows up they are shared with. If we can get DAG-JOSE structure of data - actionable configuration for public dids. Something company can stand up. Even if not complex can do it today - something that is useful we can use today. That is my goal to get those structures in place today so we get something that runs. Does that sound like a run. Dimension of discovery. Just resources (they could be streams for example). If you start out with the protected case. Then we explicitly end up having to deal with discovery. Does bob go to. if you start out with the protected case then we have to deal with discovery - then Bob goes first to so you know I’m not in charge here - if you start out with the protected case then explicitly have to deal with discovery. Does bob go first to a resource server or some authorization server and then to the resource server. In decade i’ve dealt with this - there is no right answer. But be careful how you deal with the subject.

Attendees

• Adrian Gropper
• Dan Buchner
• Joel Thorstensson
• Michael Herman
• Andreas Freund
• Charles Cunningham
• Dmitri Zagadulin
• Michael Shea
• Neil Thompson
• Wayne Chang

Recording (Zoom)

Transcript (Otter.ai)