How does one request access?

[agropper]

A requesting party, represented by a client, approaches the store, and requests access to a resource. The access request, typically has three kinds of components:

• credentials of the requesting party
• scope of access to the resource
• purpose for the request

I propose the name: Access Request for this triplet. Let the bikeshedding begin.

[agropper]

This issue is specifying an Access Request to a unit of storage about an individual subject in an interoperable way.

• We start with the purchase or provisioning of a unit of storage by some entity that might or might not be the subject themselves.

• When a request is successful, some or all of the unit will be accessed. This is the scope of the request. Available scopes are determined by the storage operator. The requesting party can't invent unsupported scopes. The storage unit purchaser, for their part, can choose among competing storage providers on the basis of scopes they make available. See also issue #39

• The request must be accompanied by credentials of the requesting party. In the absence of credentials, we are not talking about secure data stores. When the requestor is the data subject is a special case where scope and purpose are typically moot.

• The decision to authorize the scoped request may depend on the purpose for the request. Purpose is separate from scope because it is solely determined by the requesting party. A purpose is separate from a credential because they are associated with the requesting party at different times.

Therefore, units of storage of data about an individual subject must expose an Access Request interface. Interoperability across these units of storage requires standardization of the Access Request protocol.

[dlongley]

I want to note that it may not be that this sort of thing is a feature of the store. Someone may ask elsewhere/in some other way for access to something in the store. So, it may be overloading the store itself to add this feature, when it could be performed in one or more other ways.

For example, if we're using capabilities-based authorization model, a user could visit a website that requests zcaps to access one of their EDVs via CHAPI. The user could use their digital wallet to fulfill this request -- and then that website would be given zcaps to access the EDV/some particular document (and its associated stream, if any) in it.

We definitely need to consider layers here -- and that we may be talking about entirely different pieces of software/systems/mechanisms for requesting access.

[ewelton]

I tend to agree w/ @dlongley here, however, I also think that we need to remain vigilant on keeping the context of the spec congruent with the spec. I'm facing a similar issue viz-a-viz authentication - which is out of scope. My issue has resulted in is the development of a secure data store system that is independent of this secure data store system - because it stores keys and critical information used in authentication (in our case, deeply integrated with biometrics).

For example, I do not think that the intent is for the data store itself to be searchable from the outside (although this is not 100% clear yet) - in other words there is not frontier by which someone could "browse the data" and then request access - rather exacty the steps @agropper describes would take place in some other channel - producing the requisite mechanistic keys.

I think what is missing is clarity on the fact that this SDS has a specific relationship to Agents and Agent/Wallets. It is those systems, along with Users, who negotiate the data sharing between various secure data stores - and it is the Agent/Wallet that translates the policy decisions and community relationships into something that lacks semantic awareness.

I think that ZCAPs would fit the union of the above very nicely - 100% of the consent and authorization negotiation is done outside of the SDS resulting in a revocable "credential" that grants access to a specific datum (or search result?) - the SDS just enforces that mechanism, but the sensibilities about whether any given access is appropriate is out of scope.

I disagree with @dlongley that this has to do with layers - layers are inside of the scope determined by the first sections of the spec - where we understand that issues like authorization are out of scope, as are certain classes of data and other secure data stores (those containing keys and biometrics). Access Requests, consent negotiation, and revocation are similarly out of scope.

Perhaps we need a set of companion documents that support or relate to the spec - saying something is "out of scope" is too coarse grained and simplistically dismissive, especially when the parts that are out of scope have a massive impact motivating the choice of some part of the spec, like the use of ZCAPs or mechanisms of revocation checking - which would be heavily influenced by the concerns raised above. However, pulling them into the spec might widen the spec to the point where it takes too long to release.

Thus, my hope is that we identify this specific issue as one of a set of sibling issues which influence the spec by establishing context and constraints which are otherwise out of scope.

[OR13]

I agree, that requesting access is seperate from storing / authorizing retrieval... but I think that describing how it happens, even if its out of band / not in the reference implementation is critical.

The way that it works today is you tell me you want my verifiable credential,

I challenge you to did auth.

I share my edv document which has my credential with you.

I tell you you can come pick it up.

in other words, requesting and notification are handled outside of the edv, in a messaging system... potentially over transports like CHAPI or DIDComm.

[agropper]

@OR13 - I think your explanation of how it works today is vague and artificial. Please use a specific example like a grade report or driver's license... In the real world:

• It's usually not about DID auth. You are likely to care about the role or credentials of the requester, not their actual identity. You might log their identity to keep them accountable, however.
• Given a role or credential for the requester, you might infer a reason for their request and decide if the privacy loss is worth continuing with the transaction. In many cases, however, you would expect the requester to assert their intended use.
• The document / credential is almost never encrypted. It is signed, however to prevent tampering.
• "I tell you to come pick it up" I do agree with. This is where the employer as requester goes to get my grade report or letter of recommendation directly from the school.

Can we find real-world business and legal reasons for EDV as applied to personal data. Do these look like the market for Intel SGX? I can think of huge markets for cloud storage in the service of government agencies and regulated corporations but the keeper of the keys in those cases are the institutional entity not the data subject.

[OR13]

What I meant was that today, there is no invitation systems... the data controller knows (has completed did auth, seen VCs, etc...) which parties to grant access to.... and notifies them out of band.

So we are assuming some other infrastructure is needed to handle nice invitations, sms/email notifications, did comm integrations etc...

[OR13]

more discussion needed... blocked by layering discussion... lets return once we have gotten through layers.

[OR13]

@agropper can you try and document how this is related to hubs / authorization requests .... scope of request, purpose of request, credentials of requestor.

[agropper]

We likely have consensus that confidential storage is protected by a policy enforcement point (PEP). The question then is how do we describe the relationship of the PEP to some policy decision points (PDPs)?

Some PDPs will already have established a communication channel with the PEP. The obvious case is the resource 'owner' of the confidential store - the one that can delete the resource - has to have been registered at some point previous to there being a resource to protect.

The PEP might consider three cases:

Case 1: The PEP verifies a capability issued by the pre-registered PDP.

Case 2: The PEP cannot verify the capability and ignores the request. In some cases, the PEP may try to notify the pre-registered PDP or some third-party security system.

Case 3: The PEP cannot verify the capability and refers the client to the PDP.

In Case 3, the PDP is faced with a request. It hardly matters whether the request comes directly from a requesting party or as a referral from some PEP. The request, in general, may have three separate components I would call a request triplet:

• claims about the requesting party (identity, notification endpoints, client protocol capabilities and certificates, etc...)
• scope of the resources being requested (could be structured and fine-grained)
• purpose of the request (may be structured according to law such as GDPR or fine-grained)

It is important to recognize that the three components of the request triplet are orthogonal in the sense that they are established at different times by different actors.

The PDP evaluates the triplet according to policy to return a capability to the requesting party. Policy may be semi-autonomous and learning-enabled and it can include live contact with the resource owner.

The PEP may offer multiple services and expose multiple interfaces. Access to encrypted indexes are one example of an optional service in the context of an encrypted data vault. Another example of a PEP service is the resource owner registration interface. In this case, the confidential storage is advertising certain claims and capabilities rather than enforcing anything in the typical sense of the word.

A PDP may offer multiple services and expose multiple interfaces:

• Resource (PEP) registration
• Notification (of the PDP owner)
• Request triplet
• Policy management (typically restricted to the PDP owner)

Based on this, I have no idea what hubs are. A hub could:

• be a service associated with a confidential storage that bypasses the PEP by accepting requests directly;
• refer to an unencrypted index and discovery service somewhere;
• be an added or optional service offered by a PDP;
• be just a mediator (in the Aries sense) that proxies messages for multiple resource owners;
• etc...

Just as we seem to favor layering in our conversations, I PROPOSE that the Confidential Storage specification stop at the PDP (AKA agent, authorization server).

If there are other features of Confidential Storage allowed under our charter, we should try to add these to the PDP in order to facilitate and enable powerful self-sovereign and semi-autonomous agents. From a human-centered perspective, I am hoping to allow each person to consolidate as may types of requests as they want in order to make it easier for them to control artificial intelligence and machine learning as self-sovereign technology. The person, of course, preserves the choice of presenting different personas as different PDPs and each one of them can still be as aware and engaged as the person wants them to be.