[WG-UMA] Claims 2.0 proposal for discussion

[Eve Maler]

This is a draft proposal for near-term Claims 2.0 needs, based heavily on the Paul proposal and Paul/David/Nat discussions of a few months ago. Part of it can become a (very partial) generic spec if we like the way it's going, and part of it is intended to define a couple of specific claims formats for use in our May-timeframe demonstrations.

Let's try and work our way through this today. And by the way, please excuse any JSON typos and "thinkos"; I'm rather new at this -- being more of an XMLhead, as you may have guessed...

(For those who saw this in email last night, I've modified it slightly in response to a couple of comments.)

Eve

Content-type: application/json

ISSUES:
- How to bind the bearer to the subject (e.g. with signatures) for heavier-weight use cases?
- How should parameterizing work, particularly vis a vis claims-required vs. claims? E.g., can a claims schema indicate that the claims-required version is parameterized (like age-range) but the claims version is not (e.g. age)?
- Do we need more fields that apply to all claims (and claims-required), like "criticality" etc.?
- How to do claims that contain claims?
- Is it that I took out the "claim." prefix on the names of object members? May get confused with member reference syntax, e.g. S.claims-required[0].

Claims-required document template

{
"claims-required": [
{
"type": "URL-of-required-claim-type-A",
"issuer": "(URL-of-issuer1|URL-of-issuer2)",
"subject": "identifier-of-claim-subject"
},
{
"type": "URL-of-required-parameterized-claim-type-B",
"issuer": "URL-of-issuer3",
"subject": "identifier-of-claim-subject",
"URL-of-required-parameterized-claim-type-B": { "param-X": "value-for-X", "param-Y": "value-for-Y" }
}
]
}

Claims document template

{
"claims": [
{
"type": "URL-of-claim-type-A",
"issuer": "URL-of-issuer2",
"subject": "identifier-of-claim-subject"
},
{
"type": "URL-of-parameterized-claim-type-B",
"issuer": "URL-of-issuer3",
"subject": "identifier-of-claim-subject",
"URL-of-parameterized-claim-type-B": "value"
}
]
}

Proposed claims-required and claims to be used for IIW demos:

(By the way, http://tinyurl.com/claims2-0 now resolves to the top-level UMA WG wiki space. You can extend it with further URL path elements. :-)

1. Acknowledge authorizing user-driven policy

This claim type allows the requesting party to indicate agreement to the authorizing user's stated policy for this access.

The claims-required document specifies that the …acknowlauthzuserpolicy claim is required. The requesting party can self-assert that they are the subject (the claim is treated as a "bearer claim") by leaving out the subject entirely; in this case, the issuer value is understood to be the same as the subject value. The value with type "…acknowlauthzuserpolicy" is expected to be an answer to whether the authorizing user's indicated licensing policy is promised to be adhered to. (So, in this case, the claims-required and claims versions have the same amount of "parameterization".)

{
"claims-required": [
{
"type": "http://tinyurl.com/claims2-0/acknowlauthzuserpolicy",
"subject": "*",
"issuer": "*",

"http://tinyurl.com/claims2-0/acknowlauthzuserpolicy":
{
"policy": "http://creativecommons.org/licenses/by/3.0/",
"acknowledgement": "(yes|no)"
}
},
]
}

{
"claims": [
{
"type": "http://tinyurl.com/claims2-0/acknowlauthzuserpolicy",
"issuer": "http://infousa.com",
"http://tinyurl.com/claims2-0/acknowlauthzuserpolicy":
{
"policy": "http://creativecommons.org/licenses/by/3.0/",
"acknowledgement": "yes"
}
},
]
}


2. Provide requesting party-driven policy

This claim type allows the requesting party to indicate its own data usage/protection/portability policy in response to the authorizing party's request for this info. This is probably the lightest-weight claim possible, and probably is something today's web apps would be willing to do (since it amounts to just handing over the link to their existing privacy policies).

The claims-required document specifies that the …reqpartypolicy claim is required. The requesting party can self-assert a subject label that refers to itself (the claim is treated as a "bearer claim". The value of the member with type "…reqpartypolicy" is expected to be a URL that points to a versioned policy (rooted anywhere, e.g. either somewhere the requesting party has control over or not) that applies to how this requesting party promises to treat the resource for which access is being sought.

{
"claims-required": [
{
"type": "http://tinyurl.com/claims2-0/reqpartypolicy",
"subject": "*",
"issuer": "*",
"http://tinyurl.com/claims2-0/reqpartypolicy": "*"
},
]
}

(The DP.org URL is just made up for now...)

{
"claims": [
{
"type": "http://tinyurl.com/claims2-0/reqpartypolicy",
"issuer": "b...@gmail.com",
"http://tinyurl.com/claims2-0/reqpartypolicy": "http://DataPortability.org/Port1.0"
},
]
}


Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog

_______________________________________________
WG-UMA mailing list
WG-...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma

--
You received this message because you are subscribed to the Google Groups "Kantara Initiative User Managed Access WG" group.
To post to this group, send email to kantara-init...@googlegroups.com.
To unsubscribe from this group, send email to kantara-initiative...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/kantara-initiative-uma-wg?hl=en.