Hi Christian,

The purpose of the update was to clarify that Appendix B.2 of RFC 8613 could be 
used in conjunction with the ACE OSCORE profile. But as you point out, the use 
of B.2 would need to be understood between the client and server beforehand. 
There are slight differences: With B.2 there is no need to transport the access 
token again. And B.2 can be triggered by the (resource) server, if it 
understands that it does not have the right context (which can happen even if 
there is no ID context in the request). Just using the ACE OSCORE profile, the 
client would need to understand that the context is lost and run the protocol 
again. So, there is a difference but essentially the same functionality can be 
obtained.

Would it be sufficient to clarify the differences as above to address your 
comment?

Thanks,
Göran


On 2020-10-09, 17:45, "Christian Amsüss" <[email protected]> wrote:

    Hello Francesca, hello ACE group,

    On Mon, Sep 21, 2020 at 01:48:33PM +0000, Francesca Palombini wrote:
    > - clarified that Appendix B.2 of OSCORE can be used with this profile,
    > and what implementers need to think about if they do.

    I understand B.2 to be something that the involved parties need to agree
    on beforehand; after all, the ID context may be something the server
    relies on (at least for the initial attempt) to find the right key,
    especially when multiple AS are involved. (For example, the RS could
    have an agreement that the AS may issue any KID as long as they use a
    particular ID context). If the server expects B.2 to happen (which, as
    it is put now, it can as long as it supports it in general), it needs to
    shard its KID space for the ASs it uses. (Generally, B.2 is mutually
    exclusive with ID contexts's use of namespacing KIDs).

    Is the expectation that clients that do not anticipate B.2 by the time
    they are configured with their AS just don't offer B.2 to their peers?

    Given B.2 is in its current form client-initiated only (AFAIR we had
    versions where ID1 could be empty in draft versions, but currently it
    reads as client-initialized), does B.2 have any benefits for ACE-OSCORE
    clients? After all, they could just as well post the token with a new
    nonce1 to the same effect.

    Kind Regards
    Christian

    -- 
    To use raw power is to make yourself infinitely vulnerable to greater 
powers.
      -- Bene Gesserit axiom

_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace

Reply via email to