Hi Nat,
wouldn't a maleware steal the response and the cookies from the device and
replay it somewhere else. Or just steal the password? So no need to tweak the
response?
best regards,
Torsten.
Originalnachricht
Betreff: Re: [OAUTH-WG] Mix-Up and CnP/ Code injection
Von: Nat
As far as I am aware of, state was meant to be nonce. Replay possibility
etc. were known. It is probably a bad documentation that every reviewers
missed because they were assuming it.
Best,
Nat
On Mon, May 9, 2016 at 20:14 Guido Schmitz wrote:
> Hi all,
>
> can anybody confirm that this is a ne
We can also call it the “COSE Token”. As a chair of the COSE working group, I’m
fine with that amount of co-branding.
— Justin
> On May 9, 2016, at 9:31 AM, Carsten Bormann wrote:
>
>> draft-ietf-ace-cbor-token-00.txt;
>
> For the record, I do not think that ACE has a claim on the term "CBO
Hi Torsten,
No, not defeating, but being able to find out if the input is tainted or
not.
Nat
On Mon, May 9, 2016 at 07:46 wrote:
> Are you suggesting OAuth should defeat maleware? So far, this was
> considered to be handled by OS/Anti-Virus/other measures.
>
>
> Originalnachricht
Hi all,
can anybody confirm that this is a new / undocumented attack?
Cheers,
Guido, Daniel, and Ralf
On 22.04.2016 16:23, Daniel Fett wrote:
> Hi all,
>
> Besides the state leakage attack we found that another important fact
> regarding state is underspecified: Each state value should only be
> draft-ietf-ace-cbor-token-00.txt;
For the record, I do not think that ACE has a claim on the term "CBOR
Token". While the term token is not used in RFC 7049, there are many
tokens that could be expressed in CBOR or be used in applying CBOR to a
problem.
ACE CBOR Token is fine, though.
(Or, be
We got several supports and no objections, so it is concluded that the draft
is adopted as an ACE WG item, with the change that we remove the "web“ from
the name.
Authors: please resubmit the current draft as
draft-ietf-ace-cbor-token-00.txt; we will start processing further changes
in the WG proc
