On 2017-06-24 02:00, Jim Schaad wrote:
* 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.
Indeed that figure needs clarification. The errors are values not keys.
* 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.
Currently there is no recommendation, I have implemented the 3rd variant
(reject).
* 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?
My perhaps naive assumption was that the profile should be obvious to
the server, since the client will initiate the communication accordingly
e.g. send an OSCOAP message if the OSCOAP profile is to be used, or
start a DTLS handshake if the DTLS profile is to be used.
If we where to tackle this, how would we signal the profile to the
server? Securely sending messages to the server already implies the use
of a specific profile, so it seems like a hen-and-egg problem to me.
* 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?
I wonder if this functionality should be in the framework, or if it
would rather fit into another draft extending the framework. Is there a
compelling reason to have it as a base functionality?
* Per comments from other drafts. How many of these points are supposed to
be under the .well-known arch?
Good point, we should investigate this.
* 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.
I would argue that you are creating a new resource, namely the access
token, thus "create" is the right response.
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.
Indeed, that would mean that a client could access it's token with GET
and delete it with DELETE. I haven't thought through the implications,
I'll create an issue for this.
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
