OK, I was clearly misunderstanding what you were proposing.
I can see that second URI working fine without affecting existing systems. Will
update the draft.
-Original Message-
From: Jim Schaad
Sent: Thursday, February 21, 2019 10:55 PM
To: Panos Kampanakis (pkampana) ; 'Carsten Borm
Panos,
Someplace you are not understanding what I am saying.
> -Original Message-
> From: Panos Kampanakis (pkampana)
> Sent: Thursday, February 21, 2019 7:21 PM
> To: Jim Schaad ; 'Carsten Bormann'
> Cc: 'ace' ; 'Klaus Hartke'
> Subject: RE: [Ace] Embedded Content Types
>
>
> Tha
That comes with a set of problems. A simplification needs to take place. It is
probably better to just mandate one content-type for cert to get away without
complicated combined content types. We don't need to support TBD287 and 281 in
the embedded responses. It makes more sense to not do so.
The Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) specification
has been updated to address issues identified by Roman Danyliw while writing
his shepherd review. Thanks to Samuel Erdtman for fixing an incorrect example.
The specification is available at:
* https://tools.ietf
It is true that the query parameters are part of the type. However, the use of
two different URIs allows for the discovery to figure out if both versions are
supported rather than having either a failure occur because the query parameter
is not supported or getting the wrong answer back because
Panos: Please give me an email address for you that I can reach.
(Sorry for multicasting this.)
Grüße, Carsten
- The following addresses had permanent fatal errors -
(reason: 550 Connections from mailhost.informatik.uni-bremen.de
(2001:638:708:30c9::12) are being rejected du...e
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication and Authorization for
Constrained Environments WG of the IETF.
Title : Proof-of-Possession Key Semantics for CBOR Web Tokens
(CWTs)
Authors
On Feb 21, 2019, at 23:31, Jim Schaad wrote:
>
> I am thinking of two different URLs, that is not do the difference by a query
> parameter but by changing the URI.
Note that the query parameters are part of the URI, so fundamentally there is
no difference between putting the info there or in t
I am thinking of two different URLs, that is not do the difference by a query
parameter but by changing the URI. This makes it easier because the client
should be able to be deterministic about going to the same URI so it should do
the second POST to the same location and there is no need for a
> This is why I would prefer doing something like "/est/skg" and "/est/skg/yyy".
Not sure I am following. Are these two request URIs? Or in the discovery
response?
-Original Message-
From: Jim Schaad
Sent: Thursday, February 21, 2019 4:54 PM
To: Panos Kampanakis (pkampana) ; 'Carsten
> -Original Message-
> From: Panos Kampanakis (pkampana)
> Sent: Thursday, February 21, 2019 1:32 PM
> To: Carsten Bormann
> Cc: Jim Schaad ; ace@ietf.org; Klaus Hartke
> ; draft-ietf-ace-coap-...@ietf.org
> Subject: RE: [Ace] Embedded Content Types
>
> Thanks Carsten.
>
> Let's say w
Thanks Carsten.
Let's say we use a query /skg?sk=xxx&spk=yyy. /skg/xxx,yyy is a different URI
imo, so it changes the EST spec and that introduces changes that affect CAs
that already implemented it. So let's say we do /skg?sk=xxx&spk=yyy. When I am
doing resource discovery and the server is re
Carsten Bormann wrote:
> I think this is just a misunderstanding — the idea wasn’t to supply the
> parts under different URIs, but to make up different URIs for
> retrieving the different combinations coming in one multipart-core, in
> one transaction.
> or, say
> /skg/2
Hi,
For me the est-coaps solution with different URIs is a good one.
as suggested by Carsten, /skg/ctnumbers seems straightforward.
In the return of /.well-known/core, the CT hints will help. No need to
define multiple content-format combinations.
Peter
Jim Schaad schreef op 2019-02-20 18:58:
>
14 matches
Mail list logo
