Hi, Ludwig.Yes, -08 addresses the two points noted below... unfortunately you
didn't fix the various nits and the other minor issues as you indicated you
were intending to in your initial response (EC => EC2, etc).Enjoy the
holidays!Cheers,ElwynSent from Samsung tablet.
-------- Original message --------From: Ludwig Seitz <ludwig_se...@gmx.de>
Date: 21/12/2019 12:22 (GMT+00:00) To: elwynd <elw...@folly.org.uk>,
elw...@dial.pipex.com Cc: last-c...@ietf.org, gen-...@ietf.org, ace@ietf.org
Subject: Re: [Gen-art] [Ace] Genart last call review of
draft-ietf-ace-oauth-params-06 On 2019-12-19 21:23, elwynd wrote:> Hi,
Ludwig.>> Thanks for the prompt response.>> Regarding he major issue, I
understand what the intention of the split> was, but as far as early
implementations are concerned, there is no such> thing as a 'minimal breakage';
unless there is some cunning mechanism in> the basic ace-oauth-authz protocol,
changes to the structure of the> items defined here will break the protocol.
One possibility that I> could see is the addition of extra keys in the COSE_Key
dictionary> structure: In this case you could add some extra words (in the>
ace-oauth-authz document) to indicate that unrecognized keys should be>
ignored. This is associated with the editorial comments I made about> s3.1
that would allow any other keys to be present in the COSE_Key> object
structure. Similarly, the obects defined here are effectively> JSON/CBOR
dictionaries. The changes could be accomodated by adding> comments in
ace-oauth that extra keys in the items defined would be> ignored.>> In my
opinion, it would be best to remove the comments about possible> changes and
just state that they have been separated out because they> might be used in
other contexts. The possible 'changes to the> definitions' issue is just a
matter of 'institutional memory'. If there> is some mechanism, such as I
mentioned above, to accommodate changes> without neeeding an update to the
ace-oauth-authz (or other protocols> using these items), this should be
explained.I have submitted an updated draft (-08) that removes the comments
aboutpossible changes. Does this address your major issue?>> Regarding the h vs
b64 representations, since they are only examples> (and the strings are
essentially arbitrary as the actual keys aren't in> the document), I'd be
inclined to put in h representations to avoid my> question arisng.In my newly
submitted draft all the b64 representations have beenreplaced by equivalent h
representations.Note that none of these strings are arbitrary, since they do
parse toactual keys. The abbreviated b64 strings representing tokens
obviouslydo not parse as such, but come from the actual binary representation
oftokens.Happy holidays,Ludwig
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
