Double base64-url encoded claims

[jricher]

In §3.6.2.1, the text states that the claim token parameter is:

claim information in the indicated format, base64url encoded

Why the encoding restriction? What of claims already base64url encoded like JWT? Do I need to turn my JWT from this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzd
WIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4g
RG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E
2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

to this:

ZXlKaGJHY2lPaUpJVXpJMU5pSXNJblI1Y0NJN
klrcFhWQ0o5LmV5SnpkV0lpT2lJeE1qTTBOVFk
zT0Rrd0lpd2libUZ0WlNJNklrcHZhRzRnUkc5bElp
d2lZV1J0YVc0aU9uUnlkV1Y5LlRKVkE5NU9yTT
dFMmNCYWIzMFJNSHJIRGNFZnhqb1laZ2VGT
05GaDdIZ1E

before sending it in this field? This is not only wasteful in terms of processing and space overhead, but it's also counter to one of the major purposes of the JWT format: it can go in nearly any field without needing further encoding.

[xmlgrrl]

base64urlception! Oops. Yes, we meant "base64url encoded if it is not already so encoded". (We were thinking specifically of SAML when we added that.)

[xmlgrrl]

In UMA ad hoc telecon 2015-09-08 (which had quorum), this was the discussion and conclusion:

"We have rough consensus that one base64url encoding is enough! Anyone who thought otherwise would need to go and fix their V1.0 implementation."

Let's keep the change and close the issue.