...
Table of Contents
| Table of Contents | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
...
Introduction
...
signed claim: A claim object that contains a signature member attribute and associated related data.
Conventions
Following are conventions used in this specification for documenting constraints on claims-related JSON objects:
...
Name | Value | Description |
|---|---|---|
| | The identifying URL of the claim format being requested. |
| | Constraint on the value of the issuer of a supplied claim. If absent, it is acceptable for the corresponding claim to supply no issuer. (The presence of an issuer value in a supplied claim has additional implications, as noted below.) |
| Object containing attributes that are specific to the claim type | The literal values of the attributes MAY use the option and/or wildcard conventions to indicate desired constraints on the claim. |
}
For example:
| Code Block |
|---|
{
"http://c2.io/claims-requested": [
{
"type": "http://www.example.com/ABC",
"value": {
"param": 18
}
}
]
}
|
This example requests a claim conforming to the http://www.example.com/claimsformats/ABC format, whose value is an object that must contain at least a member called an attribute named param that has a number value of 18.
...
Name | Value | Description | |||
|---|---|---|---|---|---|
| | The identifying URL of the format of the claim being supplied. @@Is this object member even necessary? If another member with a name of claimURL is supplied, isn't that sufficient? Or is there benefit in having this be the very first member, even before other stuff that might get more complicated? | |||
| | The issuer of the claim. The issuer URL can be used by the recipient of the claim to retrieve the public key of the signer of a signed claim. The issuer MUST be present if a signature is present. | | Scalar value, array, or object | The value MUST conform to the claims format identified by this URL. |
| Signature object | A signature over the entire Claim object (see the Signed Claims section, below). The signature MUST be present if an issuer is present. | |||
| Object containing attributes that are specific to the claim type |
|
}
For example:
| Code Block |
|---|
{
"http://c2.io/claims": [
{
"type": "{http://www.example.com/ABC"},
{"http://www.example.com/claimsformats/ABC":"value": {
{"param": 18},
{"param2": "foo"
}
}
]
}
|
This example represents a claim supplied in response to the previous example, with a param member attribute that conforms to the template and an additional member attribute param2.
...
Signed Claims
Any Claim object can contain a signature memberattribute. The signer of the claim represents the issuer of the claim about the subject of the claim. A claim with a signature member attribute MUST also have an issuer memberattribute, and vice versa.
The Signature object is as defined in [CouchSign]. @@Need to fully define, and extend, in this spec.
A claim recipient that wishes to verify the signature of a signed claim MAY use the issuer value to construct and dereference a well-known location for the signer's "host-meta" metadata (as defined in [hostmeta]) and then obtain the signer's public key from this location by retrieving the href value an XRD <Link> element with a rel attribute whose value is http://c2.io/public-key.
For example, if the signer value is "https://signer.example.com", the claim recipient can construst construct the well-known metadata location "https://signer.example.com/.well-known/host-meta" , and perform an HTTP GET on that location to retrieve the XRD resource and obtain the signer's public key from this location.@@TBS: Define the XRD format for the key material here? Borrow some ideas from Magic Signature?
...
References
Normative References
...