...
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
...