* Figure 7 makes no sense. This appears to be mapping a string to a keyed
object. I think however, that the error here is used as a value not a key.
* Is there a recommendation for behavior if a new item is posted to the
authz-info endpoint which has the same key id as a previous one? I can
think of three answers, none of which I link
--- Just accept it - this leans to a problem because for DTLS the key ids
are single shot tries, that is one cannot try the first key and then the
second key.
--- Replace it - this means that the client associated with the current key
will suddenly be unable to access resources but knows only that the key no
longer works
--- Reject it - this may be the best option as it leaks only that the key id
is already in use, but if the key id is assigned by an AS then it may be
hard to get a different one assigned by the AS.
* We communicate the profile to be used to the client, however it is not
currently being communicated to the server. If the server wants to keep the
OSCOAP and DTLS keys separate, this needs to be done. Does it makes sense
to put this in the 'cnf' field?
* the dtls draft has the concept of a nonce in the AS information payload.
How is this propagated through the request (to the AS) and token back to the
RS?
* Per comments from other drafts. How many of these points are supposed to
be under the .well-known arch?
* In section 5.7.1 - why is there a requirement that a created rather than a
changed response be returned. I was not intending to create a new resource
in response to this POST operation. If the 2.01 (created) response is
required. Should the token be accessible using the location path in the
response? --- Same questions apply to the Client--AS interaction.
Jim
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
