I guess this is a piece of info we should have mentioned somewhere. Yes, the
idea is to use a TEE for that purpose.
At least for Arm, TrustZone for v8-M even brings TEE capabilities to the
low-end IoT devices and the first products are already on the market.
Ciao
Hannes
From: Eliot Lear [mailto
By the way, a lot *has* changed. If we can use the TEE to get signed
information out... if *it* is the attester, that's a pretty big
benefit. That just leaves the protocol gorp. But one needs to know
that there is a TEE.
On 21.06.18 22:04, Hannes Tschofenig wrote:
>
> That’s a good question, E
That’s a good question, Eliot. Let me put something together for the IETF
meeting
From: Eliot Lear [mailto:l...@cisco.com]
Sent: 21 June 2018 20:17
To: Hannes Tschofenig; oauth@ietf.org
Cc: Laurence Lundblade; e...@ietf.org
Subject: Re: [OAUTH-WG] Standardizing Attestation Tokens
Hi Hannes,
Th
Hi Hannes,
The draft is interesting, but it looks a bit like NEA. How would this
vary, apart from the CoAP part and a different registry? Seems to me
the real magic is how the device is interrogated such that the consumer
of this information has confidence as to its validity. The protocol
bits
Hi all,
I would like to make you aware of work that will be discussed on attestation on
the EAT mailing list. Here is the link to the list:
https://www.ietf.org/mailman/listinfo/eat
Here is a document describing the idea:
https://tools.ietf.org/html/draft-mandyam-eat-00
The work is relevant for
It depends on the use case but if you are talking about payment etc.,
putting the transaction details in the scope and sending it over the
regular RFC6749 redirect to the authorization server is inherently a bad
idea, as it is not protected.
My preference by far is to set up a staging endpoint and
