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 about
possible 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 been
replaced by equivalent h representations.

Note that none of these strings are arbitrary, since they do parse to
actual keys. The abbreviated b64 strings representing tokens obviously
do not parse as such, but come from the actual binary representation of
tokens.

Happy holidays,

Ludwig

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to