Re: [Json] JSON Schema Language

[Anders Rundgren <[e-mail]>]

All I'm saying is that

    https://tools.ietf.org/html/draft-handrews-json-schema-01

doesn't support alternative number serialization schemes like featured in:

    https://tools.ietf.org/html/rfc7518#section-6.3.1

It also doesn't deal with common numeric data types like ubyte, int32, uint64, float, double, BigInt etc. etc.

XML Schema shows that there is no problem having such definitions in a schema.

I leave it at there: https://github.com/json-schema-org/json-schema-spec/issues/736

Anders


On 2019-05-06 09:00, Carsten Bormann wrote:
> On May 6, 2019, at 08:33, Anders Rundgren <[e-mail]> wrote:
>>
>> IETF standards like RFC7515) have since years back rather turned to a JSON subset sometimes referred to as I-JSON (RFC 7493).
> 
> I cannot find a reference to RFC 7493 in RFC 7515 (part of JOSE).
> JOSE does not care, because it signs representations (byte strings), not data model level information.
> 
> (JOSE does need ways to represent cryptographic information that may contain numbers that might exceed implementation limits of JSON decoders.  So it represents them as text strings containing BASE64URL(*) encoded byte strings representing big-endian unsigned integers.  That has nothing to do with I-JSON, or actually only with its [incomplete(**)] suggestion to use base64url encoding for byte strings.  Section 2.2 of RFC 7493 does NOT say how to “encode [numbers] in JSON string values”.)
> 
> Grüße, Carsten
> 
> (*) Where BASE64URL is defined as base64url without padding.
> (**) RFC 7493 fails to specify encoding without padding, which, when read at face value, would mean WITH padding according to Section 5 of RFC 4648.
> Of course, we know that this isn’t what is meant.
>