How will this WG model Authorization Scopes

[OR13]

Need examples,

role, action, resource... json objects....

read:vaults / write:vaults

[OR13]

@dlongley @dmitrizagidulin can you start by pulling 100% of what EDVs support today, and just dumping it in the issue? I can do a PR if you do that.

[tplooker]

+1 a good next step is for us is to actually define what we mean by scope and clarify its relationship (or lack there of) to OAuth2.0

[dlongley]

I'm not sure yet how we want to represent this in terms of "scopes" language, but the existing EDV server/storage implementations have the following object types and allowed actions:

1. Type: EDV config, Allowed Actions: 'read', 'write'
2. Type: EDV documents collection, Allowed Actions: 'read', 'write'
3. Type: EDV document, Allowed Actions: 'read', 'write'
4. Type: EDV revoked zcaps collection, Allowed Actions: 'read', 'write'

Implementations support decentralized delegation and attenuation via zcaps. Each authorization (zcap) may optionally include an expiration datetime (and this is strongly encouraged). A zcap with 'write' access to the revoked zcaps collection may be used to submit zcaps to be marked as revoked. This zcap may be given to parties to enable them to revoke any zcap they have delegated to another party. Once a zcap is added to the revoked zcaps collection, it will no longer be usable -- and neither will any zcaps that were further delegated via its authority.

Attenuation support includes reducing the allowed actions for a particular authorization (e.g., 'read'+'write' access can be reduced to just 'read' or just 'write'), shorter expiration periods, and a zcap for a document collection (i.e., access to all documents in an EDV) may be attenuated such that it only grants authority to a particular document in that collection instead of the entire collection.

Having a zcap with 'write' access for a particular document (or for the whole collection of documents) enables a party to write to the document, write any chunks associated with its stream, if it has one, and write to/update encrypted indexes. There are no use cases for splitting this authority and doing so would be problematic since current designs store both encrypted index information and encrypted stream and chunk metadata in the document. The 'read' access is similar but allows reading the encrypted document and its encrypted chunks instead. In order to perform a query across the entire collection of documents, a zcap with 'read' access for the entire collection is required, not just a single document within the collection.

Note that none of these authorizations enable a party to decrypt encrypted content. Either direct access to decryption keys/key agreement keys or a zcap that enables a key agreement operation to be performed via WebKMS is required in current implementations. Note that WebKMS is a separate technology (also making its way through the standardization process via the W3C CG) that can be optionally used here, it is not a requirement for EDVs. In short, access to decryption key material, the ability to generate a decryption key, or access to use a service that performs key agreement without giving direct access to key material is out of scope for EDV server authorizations -- because this all has to do with clients instead.

[agropper]

Thanks, @dlongley for the clear introduction in terms of EDVs and highlighting the distinction between a requesting party (often an identity) and a client (typically a thing). In almost all real-world cases, the authorization or capability is directed to a an accountable requesting party rather than the particular user agent or client that is a delegate of the requesting party.

Lest we forget, this WG is about Secure Data Stores and, I presume, that means we need to deal with access to the content rather than just the encrypted content. As I have said before, the vast majority of personal or private data out there is being held in the clear because it originated with the holding entity or it was processed in the clear by the holding entity.

The possible scopes of authorization are determined solely by the holding entity. A capability outside those available will be rejected. Standards may or may not be involved. Does anyone argue with this?

Any secure data store may receive an access request. That request can come in one of two ways:

• a capability in the form of a bearer token that specifies the scope and automatically trusts the client, or
• a request that can be turned into a capability by referencing an authorization server.

Are there any other possibilities for securing a data store?

It is up to the authorization server, wherever it is, to understand the available scopes, the requested scope, the purpose of the request and the credentials of the requesting party as well as the trustworthiness of whatever client will be used to access the store. If the authorization server is confused, it needs to deal with the requesting party directly or through their client but this is invisible to the secure data store.

Here are two references directly related to Authorization Scopes:

• On the path to GNAP / OAuth3
• As seen from the OAuth2 perspective

My hope is that we align with GNAP and move on because it puts the most control in the hands of whoever controls the authorization server and reduces the costs and risk of the secure data store to a minimum.

[OR13]

@agropper can you propose concrete examples of how you want the scopes dave mentioned above to look, use GNAP / OAuth3, and make a concrete proposal.

Here is my concrete proposal for how we should define scopes.

Lets follow the example set by google: https://cloud.google.com/storage/docs/access-control/iam-permissions

Type: EDV config, Allowed Actions: 'read', 'write'
Type: EDV documents collection, Allowed Actions: 'read', 'write'
Type: EDV document, Allowed Actions: 'read', 'write'
Type: EDV revoked zcaps collection, Allowed Actions: 'read', 'write'

Becomes:

vault.config.get vault.config.update 
vault.documents.get vault.documents.update
vault.document.get vault.document.update 
vault.capabilities.get vault.capabilities.update 

[agropper]

Here are two concrete examples:

HL7-FHIR : Where a huge amount of data model standards work has been done and widely adopted across an entire sector.

GNAP: The Resources section on this page where the standardization of the data model has not yet occurred. In this case, as with other aspects of SSI, we want to encourage published schemas and data model standards.

[OR13]

@agropper neither of those are concrete proposals for how permissions related to the resources in a data vault should be designed....

HL7-FHIR is used all over the place, but for healthcare.... probably this is a better starting point: http://hl7.org/fhir/smart-app-launch/scopes-and-launch-context/index.html ... Im interested to hear how much of HL7-FHIR you think this WG should import.... I'd hesitate to use any of it, but I have scars from working in healthcare.

.... AFAIK, nobody is actually using GNAP currently.

Here is what I mean (taking from the second example and modified):

{
    "type": "example.com/vaults/:guid/documents,
    "actions": [
        "read",
        "write",
    ],
    "locations": [
        "https://server.example.net/",
        "https://resource.local/other"
    ],
    "datatypes": [
        "metadata",
        "images"
    ]
}

it looks sorta broken, because I don't understand how GNAP works... can you provide a none broken example thats more less equal to my proposal / the google example I provided?

[agropper]

I urge all of you that think about authorization to watch this Identiverse talk by Justin Richer. OAuth3 intro. https://youtu.be/U9i7YaN8v9c

I plead with you, whether working on DID core or Secure Data Stores, to take authorization MORE seriously than authentication. Authentication is about security, and, for the most part nobody argues with better security. But the rate-limit on adoption of SSI is clearly going to be privacy, not security. EFF gets it right: https://www.eff.org/deeplinks/2020/08/digital-identification-must-be-designed-privacy-and-equity-10 Mozilla gets it right https://foundation.mozilla.org/en/initiatives/data-futures/data-for-empowerment/

The business and regulatory pressure to avoid authorization agency and data use transparency is unrelenting. SSI must also lead to self-sovereign agency. Pretending that manual control over presentation is a solution to authorization is overly simplistic and does not scale. My 1Password file has almost 300 service relationships in it. It's all about identity and authentication. It doesn't touch authorization. Does anyone believe that a DID and VC-enhanced 1Password will make a significant difference?

How many of the 300 service relationships in your wallet will be improved by being able to manually set "read", "write", "images" and "metadata"?

How many of the folks on this list have had to work with OAuth2 and static client registration? We have to do better if we want SSI to succeed. I know of no viable alternative to GNAP.

If my privacy argument does not have you convinced, consider the security argument around Zero-Trust Architecture and it's requirement for data minimization as well as transparency to the data subject. A self-sovereign, semi-autonomous authorization server is essential.

On Mon, Sep 28, 2020 at 6:02 PM Orie Steele notifications@github.com wrote:

@agropper https://github.com/agropper neither of those are concrete proposals for how permissions related to the resources in a data vault should be designed....

HL7-FHIR is used all over the place, but for healthcare only probably this is a better starting point: http://hl7.org/fhir/smart-app-launch/scopes-and-launch-context/index.html ... Im interested to hear how much of HL7-FHIR you think this WG should import.... I'd hesitate to use any of it, but I have scars from working in healthcare.

.... AFAIK, nobody is actually using GNAP currently.

Here is what I mean (taking from the second example and modified):

{ "type": "example.com/vaults/:guid/documents, "actions": [ "read", "write", ], "locations": [ "https://server.example.net/", "https://resource.local/other" ], "datatypes": [ "metadata", "images" ] }

it looks sorta broken, because I don't understand how GNAP works... can you provide a none broken example thats more less equal to my proposal / the google example I provided?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/decentralized-identity/secure-data-store/issues/107#issuecomment-700307889, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YITAKJBW7HCNIOXWJTSIEBW3ANCNFSM4RYYMILQ .