Please find some notes on possible data model for the policy resource. Currently looking at uma required_claims, did/vc, rar and zcap
## UMA style required_claims
pulled from UMA Grant:
```
required_claims
An array of objects that describe the required claims, with the following subparameters:
claim_token_format
OPTIONAL. An array of strings specifying a set of acceptable formats for a claim token pushed by the client containing this claim, as defined in Section 3.3.1. Any one of the referenced formats would satisfy the authorization server's requirements. Each string MAY be a URI.
claim_type
OPTIONAL. A string, indicating the expected interpretation of the provided claim value. The string MAY be a URI.
friendly_name
OPTIONAL. A string that provides a human-readable form of the claim's name. This can be useful as a "display name" for use in user interfaces in cases where the actual name is complex or opaque, such as an OID or a UUID.
issuer
OPTIONAL. An array of strings specifying a set of acceptable issuing authorities for the claim. Any one of the referenced authorities would satisfy the authorization server's requirements. Each string MAY be a URI.
name
OPTIONAL. A string (which MAY be a URI) representing the name of the claim; the "key" in a key-value pair.
```
ADD NEW field
```
value: the required value(s) of this claim??
```
Q. I don't understand the distinction between claim_type, name (and display_name)
A? The name is the expected 'key' in the token, and the claim_type is how to interpret that key??? As defined by the AS since it interprets the claims?
Let's try to represent a policy as would be used by google drive to share a file.
This is the same as would be presented to the client (@ token endpoint) without the 'values' field
```
resource_id: 'some docuement',
resource_scopes: [
comment
]
required_claims: [
{
"claim_token_format":[
],
"claim_type":"email",
"issuer":[
],
"name":"email_key_in_token"
},
]
```
How about to share my patient record with any researcher from university. I need their sub to record access.
```
scopes: [ read ]
required_claims: {
"claim_token_format":[
],
"claim_type":"sub",
"issuer":[
],
"name":"sub"
},
{
"claim_token_format":[
],
"claim_type":"purpose",
"issuer":[
],
value: "research"
}
```
Requiring agreements to a specific purpose/tos/ethics statement
```
{
"claim_token_format":[
"JWT"
],
"claim_type":"tos",
"issuer":[
],
"name":"tos"
},
JWT payload = {
}
```
or it could require a consent receipt (the RO has given consent to the RqP, which they are redeeming)
```
{
"claim_token_format":[
"kantara/consentreceipt/1.1.0"
],
"claim_type":"consent_receipt",
"issuer":[
],
},
claim payload = consent receipt json
```
Can the RO specify approved clients?? this doesn't seem to fit into required_claims... although the rqp may be choosing the client software?
```
{
"claim_token_format":[
"JWT"
],
"claim_type":"client_id",
"issuer":[
],
"name":"client_id"
values: [
clienta_known_to_as,
]
},
```
Can the RO specify (required acr of rqp)
```
scopes: [ read ]
required_claims: {
"claim_token_format":[
],
"claim_type":"acr",
"issuer":[
],
value: 'urn:whatever:gold'
},
```
Notes/Questions:
could the `issuer` also be the CA/TTP?? Or has to be the direct `iss` in presented token (ie the signer...). How can a policy say 'any token approved through this "trust framework"?'
Can there be many required claims with the same name/claim_type?? ie, array of values
with many required_claims... would/can claims_token_format differ? The client may only provide one claims at time through the token endpoint. Token endpoint can always return a new ticket with the 'remaining' required claims, until the policy is met or all are presented. The client could repackage many tokens into a jwt with claims_sources or such
Even if all required_claims are presented, it can still result in a deny result!
should there be the ability to apply policy against resource_id/scope sets, similar to the permission api? This need would vary depending on the resource type/registration model at the RS
no clear way to create policy beyond... required claims from the rqp. Ex can/should the RO have any ability to influence expiration times etc
Is it possible to make the presented claim a requirement of the client vs the rqp?
If the iss is the AS, does it imply it requires interactive claims gathering?
## Looking at DID/VCs
withing the uma required_claims schema we could fit vc as a claim type
The id in the presented VC must match the value `did:whatever:didvalue`
```
{
"claim_token_format":[
],
"claim_type":"did",
"issuer":[
"did:whatever:issuerdid
],
"name" : "id"
"value":"did:whatever:didvalue"
},
{
"claim_token_format":[
],
"claim_type":"university_degree",
"issuer":[
"did:whatever:issuerdid
],
"name" : "id"
"value":"did:whatever:didvalue"
}
```
An issue here is that the RqP needs to know which DID to present to this AS in order to meet the policy. this only works if the Rqp knows the request is in the context of a specific RO (sort of...) to know which did to present
This is the "same" as needing to know a email, however email is more public by definition while a did may be pairwise by design ()
VC's are a token package type like OIDC IDToken. There is some predefined, but extensible attribute sets, and arbitrary claims can be asserted by issuers about the rqp
## Looking at RAR
```
"type": The type of resource request as a string. This field MAY
define which other elements are allowed in the request. This
element is REQUIRED.
This field MUST be compared using an exact byte match of the string
value against known types by the AS. The AS MUST ensure that there
is no collision between different authorization data types that it
supports. The AS MUST NOT do any collation or normalization of data
types during comparison.
This draft defines a set of common data elements that are designed to
be usable across different types of APIs. These data elements MAY be
combined in different ways depending on the needs of the API. All
data elements are OPTIONAL.
"locations": An array of strings representing the location of the
resource or resource server. This is typically composed of URIs.
"actions": An array of strings representing the kinds of actions to
be taken at the resource. The values of the strings are
determined by the API being protected.
"datatypes": An array of strings representing the kinds of data
being requested from the resource.
"identifier": A string identifier indicating a specific resource
available at the API.
```
As defined, a RAR is pushed by a RP to the AS to indicate what resource they want access to. This is quite similar to the UMA RS permission endpoint, where the RS indicates what resources (type/identifier) and scopes (actions) it interprets for the client request.
I am not clear how this could be used to model RO policy (very useful in resource definitions/indicators context)
Possibly it could be used to model the resource definition side (ie replace the simple resource_id/scopes above) such that policy can be applied more generally instead of against specific resources. The RAR json would sit next to one of the other policy formats (required_claims array)
## Looking at ZCAP
It is the claim unto itself, unlike VC's there are no actual claims in the ZCAP
The zcap allows the invoker to perform some action(?) against the root 'parentCapability' The car in the example, also defines the scopes in some ways. The parentCapability could be a ticket from the permission api "there are the resources and scopes I am delegating to X"
The zcap can be registered as policy at the AS, or given directly from ro->rqp?
The root parentCapability=resource_id, invoker=rqp required proof
Not clear how the AS can make a decision over this policy if it's not in the delegation chain? How could it invoke the capability such that the RS would allow it?
- Avoid this by making the AS issue the initial zcap to the PM, instead of from RS->PM... this hides the zcap between AS/PM so RS need not know about it (similar to required_claims)
1. PM resource api would return a ZCAP?
2. PM would push a delegatedCapability as a policy back to the AS
3. a RqP must invoke the policy when it tries to access the resource
```
DELEGATION FROM RS to RO??? (outside of RO?)
// arbitrary policy constraints
"caveat": [
{"type": "ValidWhileTrue",
{"type": "ExpiresAt",
"uri": 2345564<some future timestamp>}
],
// this would require the RS to initially grant Alyssa the capability
"proof": {
"type": "RsaSignature2016",
"proofPurpose": "capabilityDelegation",
"created": "2016-02-08T16:02:20Z",
"signatureValue": "IOmA4R7TfhkYTYW8...CBMq2/gi25s="}}
PRESENTATION (claims presentation):
"id": "urn:uuid:ad86cb2c-e9db-434a-beae-71b82120a8a4",
"action": "Drive",
"proof": {
"type": "RsaSignature2016",
// A linked data document can be an invocation if it has a
// proofPurpose of capabilityInvocation and links to the capability
// chain it is invoking
"proofPurpose": "capabilityInvocation",
"created": "2016-02-08T17:13:48Z",
"signatureValue": "..."}}
```
Delegation Policy from Alyssa to Bob
```
// Pointing up the chain at the capability from which Alyssa was
// initially gained authority
// Alyssa grants authority specifically to one of Ben's
// cryptographic keys
// Alyssa adds a caveat: Ben can drive her car, unless she flips
// the bit at this url
"caveat": [
{"type": "ValidWhileTrue",
// Finally Alyssa signs this object with the key she was granted
// authority with
"proof": {
"type": "RsaSignature2016",
"proofPurpose": "capabilityDelegation",
"created": "2017-03-28T06:01:25Z",
"signatureValue": "..."}}
```