Re: [Rats] EAT as a JWT/CWT

On 2019-05-27 18:37, Henk Birkholz wrote:
> Hi Giri,
> 
> as the JCS effort (that still might have to prove itself)
> 
>> https://datatracker.ietf.org/doc/draft-rundgren-json-canonicalization-scheme/
> 
> shows, the question on how to serialize JSON in a manner that renders
> signing and validation a simple task is still an open one.

JCS actually works great :)  Everything is though not completely transparent.

However, converting a 64-bit integer in CBOR to JSON doesn't have a clear definition.
The EAT authors are therefore essentially on their own if this is what is required.

I would personally abstain from such endeavors.

Anders
JSON serialization guru.

> 
> Jumping from that to an "agreed-upon methodology for casting a CWT (EAT)
> to a JWT" might be a quite big jump (maybe omitting some carefully
> considered steps in between). I am not trying to say that it is
> impossible or unfeasible, just that there are quite some factors to take
> into account here.
> 
> Viele Grüße,
> 
> Henk
> 
> 
> On 5/27/19 6:07 PM, Giridhar Mandyam wrote:
>>>>> AFAIK the FIDO do not use JWT, neither does Android.
>>>
>>>> FIDO 2 allows for the Android SafetyNet Attestation, which is generally considered to return its response as a JWT:  https://medium.com/@herrjemand/verifying-fido2-safetynet-attestation-bd261ce1978d.  The actual SafetyNet attestation documentation lists the returned object as a JWS:  https://developer.android.com/training/safetynet/attestation.
>>
>>> Yes.  But why would you want to do this for new stuff?
>>
>> That was not really what I was intending to address.  There was an inaccurate comment on the mailing list, and I was putting out a clarification.
>>
>> But since you asked, in general with CBOR/COSE/CWT specifications, there is not (IMO) sufficient consideration with respect to interoperability with legacy systems.  What I personally would like to see is a general methodology for casting CWT's to JWT's and vice versa, and x.509's to CBOR certs.  Granted, contributions such as https://tools.ietf.org/html/draft-raza-ace-cbor-certificates-01 seem to begin to address this topic, but such efforts are nascent and it is unclear whether they will achieve widespread adoption.
>>
>> In the absence of a agreed-upon methodology for casting a CWT (EAT) to a JWT, then we cannot really guarantee that EAT -> JWT transcoding will achieve the intended result.  We could of course insist that all implementors just accept EAT as the future and not worry about legacy interop, but (based on my experience) this is a tough sell to service providers who have invested a lot in their existing authentication systems.
>>
>> Note that I have not performed an extensive survey on CBOR/JSON interoperability.  If there is some emerging methodology that will address these issues, then I would say that we wouldn't need to worry about how EAT is cast to a JWT.  We could just point to such a methodology and call it a day.
>>
>> -Giri
>>
>> -----Original Message-----
>> From: Carsten Bormann <cabo@tzi.org>
>> Sent: Monday, May 27, 2019 8:29 AM
>> To: Giridhar Mandyam <mandyam@qti.qualcomm.com>
>> Cc: rats@ietf.org
>> Subject: Re: [Rats] EAT as a JWT/CWT
>>
>> On May 27, 2019, at 17:01, Giridhar Mandyam <mandyam@qti.qualcomm.com> wrote:
>>>
>>>> AFAIK the FIDO do not use JWT, neither does Android.
>>>
>>> FIDO 2 allows for the Android SafetyNet Attestation, which is generally considered to return its response as a JWT:  https://medium.com/@herrjemand/verifying-fido2-safetynet-attestation-bd261ce1978d.  The actual SafetyNet attestation documentation lists the returned object as a JWS:  https://developer.android.com/training/safetynet/attestation.
>>
>> Yes.  But why would you want to do this for new stuff?
>>
>> Of course, you may need to ship around legacy data.  X.509 certificates, some JWS, etc.
>> But the new EAT tokens?  Why create diversity that virtually doubles specification, implementation, and validation effort?
>>
>> Grüße, Carsten
>>
>> _______________________________________________
>> RATS mailing list
>> RATS@ietf.org
>> https://www.ietf.org/mailman/listinfo/rats
>>
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
> 