On 2022-02-22, at 20:45, Laurence Lundblade wrote:
>>
>>> The main example I can think of is EAT in pure HW (e.g., a TPM-like chip
>>> that outputs EAT). Outputting fixed length integers will make that HW
>>> simpler.
>>
>> Any CBOR decoder will be happy with decoding this.
>
> True, but
I’ve put the text that EAT has profiles CBOR encoding in below.
> On Feb 22, 2022, at 11:09 AM, Carsten Bormann wrote:
>
> On 2022-02-22, at 18:08, Laurence Lundblade wrote:
>>
>> EAT allows for use of the different CBOR serializations just like COSE and
>> CWT so particular deployments can
On 2022-02-22, at 18:08, Laurence Lundblade wrote:
>
> EAT allows for use of the different CBOR serializations just like COSE and
> CWT so particular deployments can choose what is best for them. It is
> important to continue to allow all serializations in EAT for the reasons that
> they
Dear COSE working group members,
Do you have proposed agenda items for our session at IETF 113 in Vienna? If
so, please reply-all to this note. Include a title, the presenter(s), and
proposed amount of time you'd like.
We have a slot for 13:00-14:00 on Monday Afternoon.
I'm looking
EAT allows for use of the different CBOR serializations just like COSE and CWT
so particular deployments can choose what is best for them. It is important to
continue to allow all serializations in EAT for the reasons that they exist in
the first place.
The main example I can think of is EAT
Hi Anders,
> The WebAuthn/FIDO specification details CBOR serialization requirements
(As does COSE *for its internally constructed signing inputs*, not for what
goes over the wire.)
> while the EAT draft specifies multiple alternatives.
Maybe we need to fix that then.
> There must be a
On 2022-02-22 10:08, Carsten Bormann wrote:
>>
On 2022-02-22, at 06:59, Anders Rundgren wrote:
However, due to the myriad of CBOR serialization options,...
Not true.
All widely used serialization formats grant the encoder some freedoms in
encoding information, CBOR is not different. There
Hi Anders,
> On 2022-02-22, at 06:59, Anders Rundgren
> wrote:
>
> On 2022-02-21 17:31, Carsten Bormann wrote:
>> On 2022-02-21, at 17:15, Anders Rundgren
>> wrote:
>>>
>>> I couldn't find any valid reason for using JSON
>> We seem to have found an area where we agree :-)
>
> In this
