Subject: [jose] Attribute certificates

From: Luke Howard <[email-masked]>
Date: Mon, 9 Dec 2013 11:57:16 +1100

I've been prototyping JWT attribute certificates in Mozilla Persona. [1]

Attribute certificates claim a subset of attributes about an identity and are intended to be selectively disclosable at presentation time in conjunction with a primary certificate. They are regular JWTs with the following reserved claims:

* A claim representing a binding to a primary certificate (currently, this is the "cb" claim containing the SHA-256 hash of the primary certificate JWT)

* A claim identifying the nature of the other claims made in the attribute certificate (currently, this is "id"). A user presenting a fresh attribute certificate with the same id meta-claim as a previous one should have confidence that it represents the same aspects of their identity.

* A claim containing a human readable description of the attribute certificate

My current implementation requires that the attribute certificate issuer be the same as the primary certificate, but with a suitable trust model there's no reason attribute certificates from different issuers could not be supported. An attribute may have a shorter validity time than the primary certificate.

I'm wondering if there's any interest in documenting this, I think they may be useful irrespective of Persona. (There are a bunch things I need to clean up, such as conveying the certificate binding hash algorithm.)

-- Luke

[1] https://groups.google.com/forum/#!topic/mozilla.dev.identity/kWhiJWH9AV0

---

From: Brian Campbell <[email-masked]>
Date: Tue, 10 Dec 2013 13:03:04 -0700

You might want to pose the same questions to the OAuth WG (
https://www.ietf.org/mailman/listinfo/oauth).  That's where the JWT work is
being done. The JOSE WG is working on JWS, JWT and JWK, which are used by
JWT but, strictly speaking, the concept of a claim isn't meaningful at the
JOSE layer.

On Sun, Dec 8, 2013 at 5:57 PM, Luke Howard <[email-masked]> wrote:

> Attribute certificates claim a subset of attributes about an identity and
> are intended to be selectively disclosable at presentation time in
> conjunction with a primary certificate. They are regular JWTs with the
> following reserved claims:
>
> * A claim representing a binding to a primary certificate (currently, this
> is the "cb" claim containing the SHA-256 hash of the primary certificate
> JWT)
>
> * A claim identifying the nature of the other claims made in the attribute
> certificate (currently, this is "id"). A user presenting a fresh attribute
> certificate with the same id meta-claim as a previous one should have
> confidence that it represents the same aspects of their identity.
>
> My current implementation requires that the attribute certificate issuer
> be the same as the primary certificate, but with a suitable trust model
> there's no reason attribute certificates from different issuers could not
> be supported. An attribute may have a shorter validity time than the
> primary certificate.
>
> I'm wondering if there's any interest in documenting this, I think they
> may be useful irrespective of Persona. (There are a bunch things I need to
> clean up, such as conveying the certificate binding hash algorithm.)
>
> -- Luke
>
> [1]
> https://groups.google.com/forum/#!topic/mozilla.dev.identity/kWhiJWH9AV0
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 10 Dec 2013 15:19:01 -0500

It's not immediately clear to me that JWT is an exceptionally good fit
here.  It seems like there might be a separate WG here to look at
(effectively) JSON equivalents for X.509 certs and attribute certs.

On Tue, Dec 10, 2013 at 3:03 PM, Brian Campbell
<[email-masked]>wrote:

> https://www.ietf.org/mailman/listinfo/oauth).  That's where the JWT work
> is being done. The JOSE WG is working on JWS, JWT and JWK, which are used
> by JWT but, strictly speaking, the concept of a claim isn't meaningful at
> the JOSE layer.
>
>
>> * A claim representing a binding to a primary certificate (currently,
>> this is the "cb" claim containing the SHA-256 hash of the primary
>> certificate JWT)
>>
>> * A claim identifying the nature of the other claims made in the
>> attribute certificate (currently, this is "id"). A user presenting a fresh
>> attribute certificate with the same id meta-claim as a previous one should
>> have confidence that it represents the same aspects of their identity.
>>

---

From: Luke Howard <[email-masked]>
Date: Wed, 11 Dec 2013 13:13:32 +1100

On 11 Dec 2013, at 7:19 am, Richard Barnes <[email-masked]> wrote:

> It's not immediately clear to me that JWT is an exceptionally good fit here.  It seems like there might be a separate WG here to look at (effectively) JSON equivalents for X.509 certs and attribute certs.   

BrowserID uses JWTs as equivalents for X.509 certificates, so my proposed use of attribute certificates is just an extension of that. Here are some docs, hopefully it's easy to separate the BrowserID-specific implementation notes from the data format:

https://github.com/lhoward/browserid/blob/lhoward-sad/docs/ATTRIBUTE_CERTS.md

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Wed, 11 Dec 2013 13:17:06 +1100

One thing that would be immediately useful is any thoughts on whether that are existing claim IDs that may be used for:

* an identifier that groups a set of claims in a JWT; as opposed to "jti", which is unique per instance, different JWTs over time with this meta-claim may be assumed to express equivalent claims about a subject. (I suppose in one way, "sub" would make sense. Currently I'm using "id".)

* a human readable display name for the set of claims in a JWT. Currently I'm using "dn".

cheers,
Luke

---

From: Luke Howard <[email-masked]>
Date: Wed, 11 Dec 2013 14:41:44 +1100

Also, I want to algorithm agonstify the certificate digest claim - are there any specifications for hash functions that are unkeyed? I presume "S256" for SHA-256 (etc) is the obvious answer.

Sent from my iPhone

> On 11 Dec 2013, at 13:17, Luke Howard <[email-masked]> wrote:
>

---

From: Luke Howard <[email-masked]>
Date: Thu, 12 Dec 2013 01:10:06 +1100

> * an identifier that groups a set of claims in a JWT; as opposed to "jti", which is unique per instance, different JWTs over time with this meta-claim may be assumed to express equivalent claims ab…

Apologies for the list traffic. It appears that "scope" is the right thing to use here (and I realise such claims are out of scope for JOSE; I will go bother OAuth instead).

I've also defined the RFC 3281-inspired "cdi" (certDigestInfo) as an object that contains two properties: "alg" (S256 for SHA-256, etc) and "cdi" (base64URL encoded digest). I'll write this up in an IETF draft soon.

> * a human readable display name for the set of claims in a JWT. Currently I'm using "dn".

Maybe "sdn" is better. Or "scope_display_name". Or "display_name".

-- Luke

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 11 Dec 2013 15:55:11 +0100

Hi Luke,
You may find the JCS (JSON Clear-text Signature) scheme suitable for your task:
http://webpki.org/papers/keygen2/doc/jcs.html

JCS was explicitly designed for supporting information-rich JSON-based systems.

You can also test it on the web:
https://mobilepki.org/jcs

Cheers,
Anders