On Fri, Aug 24, 2012 at 12:17 AM, Justin Richer <[email protected]
<mailto:[email protected]>> wrote:
That extension was never proposed, so I would wager that the
multi-token case was at least rare enough to not force the
standardization question.
Actually, we decided to do it as an extension, called OpenID Connect.
Userinfo endpoint actually returns multiple tokens.
Just to clarify -- this isn't quite the same thing. What folks had been
asking about was not multiple different kinds of tokens at once, which
the existing JSON structure makes amenable, but multiple parallel access
tokens, each with their own values and (potentially) metadata. The two
tokens that Connect returns have different purposes, different
audiences, potentially very different formats and structures. This is
why they come back as two tokens in different members, "access_token"
and "id_token". What was discussed on the group was more the case where
you'd have an array of "access_token" values.
I think the same approach should be taken here. Keep the existing,
deployed, simple format of header.payload.signature for the simple
single-signature case. Use a different serialization format for
different use case, such as the JWS-JSON format that Mike's
proposed or the multi-dot format proposed below. I would argue
that they're fundamentally different kinds of objects and that
conflating their use cases by forcing the overhead is a big mistake.
+1
Note: I have a multi-signature use case that I have to solve, but I
believe for the adoption purpose, we should be focused on the main use
cases.
Right, there are definitely use cases for this, but I think that it's a
different solution that's needed here. There isn't always a nice, single
general abstraction.
-- Justin
-- Justin
On 08/20/2012 04:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
Here is my view: the muliple recipient case is a rare case.
Having a bit of extra overhead for rare cases is IMHO acceptable
to keep the core spec simpler.
hannes
Sent from my Windows Phone
------------------------------------------------------------------------
From: ext Richard L. Barnes
Sent: 8/18/2012 12:58 AM
To: [email protected] <mailto:[email protected]>
Subject: [jose] Splitting headers
Hey all,
At IETF 84, I suggested that we take another look at what header
information gets integrity-protected and what doesn't. The main
issue being that in multiple-recipient or multiple-signer
scenarios, there's unnecessary duplication of data if recipient-
or signer-specific information is in the integrity-protected header.
Following some on what Bob Wyman proposed this afternoon, I would
like to propose that we split the set of header fields into some
logical groupings:
1. Top-level fields that require integrity protection (e.g., cty
or a digest algorithm parameter)
2. Top-level fields that do not require integrity protection
(e.g., x5c)
3. Fields that are specific to a signer (e.g., jwk)
4. Fields that are specific to a recipient (e.g., epk)
In this taxonomy, only fields of type (1) need to be
base64-encoded for to preserve their serialization, and fields of
type (3) and (4) could be gathered together into the moral
equivalent of SignerInfo and RecipientInfo objects. All this
makes the JSON serialization a lot cleaner, for example:
{
"type": "S",
"header": "[base64-type1]",
"params": { /* type2 */ },
"content": "[base64-content]",
"signers": [
{ /* type3 */ }
]
}
You can also imagine a reasonable compact serialization,
something like:
S.[base64-type1].[base64-type2].[base64-content].[base64-signer1].[base64-signer2].
...
That encoding even has the benefit that the multi-signer case
doesn't add any overhead over the single-signer case, except for
maybe a couple of "." characters. (Obviously, you would want some
structure on how the signer info gets serialized, but that's
another level of detail down. You could imagine something like
"[signer-header].[public-key].[signature-value]".)
The additional structure might seem like it's more work to parse,
but I don't think it's really that bad. Given a parsed JOSE
object "obj":
1. Decode obj.header and add its fields to obj.params
2. Look through "signers" / "recipients" to find one we understand
3. Verify / decrypt content using signer/recipient info and
parameters
There are several details to be worked out -- most critically,
which fields go in which groupings -- but I thought I would throw
out the general idea for comment before diving into the details.
Cheers,
--Richard
_______________________________________________
jose mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
