icrosoft.com]
Sent: 07 February 2018 17:27
To: Göran Selander; Hannes Tschofenig; OAuth@ietf.org
Cc: draft-ietf-core-object-secur...@ietf.org
Subject: RE: [OAUTH-WG] OSCORE
As Göran said, yes the original rationale was end-to-end communication through
proxies where each leg might be CoAP or migh
Wednesday, February 7, 2018 8:00 AM
To: Hannes Tschofenig ; OAuth@ietf.org; Dave Thaler
Cc: draft-ietf-core-object-secur...@ietf.org
Subject: Re: [OAUTH-WG] OSCORE
Hi Hannes,
Including Dave who may want to provide some background to the use case.
As I said, this was a proposed constructi
February 7, 2018 8:00 AM
To: Hannes Tschofenig ; OAuth@ietf.org; Dave Thaler
Cc: draft-ietf-core-object-secur...@ietf.org
Subject: Re: [OAUTH-WG] OSCORE
Hi Hannes,
Including Dave who may want to provide some background to the use case.
As I said, this was a proposed construction and was straight
Hi Hannes,
Including Dave who may want to provide some background to the use case.
As I said, this was a proposed construction and was straightforward to
include in the draft. I’m not the right person to answer whether this is
useful for OAuth, but I’m interested in the answer.
Göran
On 2018-0
Hi Göran,
Maybe you can then answer the question whether this is useful / applicable to a
HTTP. Asked differently, under what conditions does the OSCORE not work for
HTTP. This would help the folks in the group, including me, to determine
whether this actually something we should be looking int
