Change:
mandate the use of the sector parameter on all operations, as no credentials are suitable for operations across sector borders anyway. <ins> 7.5. The First-Come-First-Remembered policy is provided both as a reference example for a security policy definition, and as a policy that implementations may choose to use as default policy in absence of other configuration.  It is designed to enable efficient discovery operations even in ad-hoc settings. Under this policy, the RD accepts registrations for any endpoint name that is not assigned to an active registration resource, and only accepts registration updates from the same endpoint.  The policy is minimal in that towards lookup clients it does not make any of the claims of entered-resources and link-confidentiality, and its claims on secure-ep are limited to the lifetime of that endpoint's registration.  It does, however, guarantee towards any endpoint that for the duration of its registration, its links will be discoverable on the RD. When a registration or operation is attempted, the RD MUST determine the client's subject name or public key: If the client's credentials indicate any subject name that is certified by any authority which the RD recognizes (which may be the system's trust anchor store), all those subject names are stored.  With CWT or JWT based credentials (as common with ACE), the Subject (sub) claim is stored as a single name, if it exists. With X.509 certificates, the Common Name (CN) and the complete list of SubjectAltName entries are stored.  In both cases, the authority that certified the claim is stored along with the subject, as the latter may only be locally unique. Otherwise, if the client proves possession of a private key, the matching public key is stored.  This applies both to raw public keys and to the public keys indicated in certificates that failed the above authority check. If neither is present, a reference to the security session itself is stored.  With (D)TLS, that is the connection itself, or the session resumption information if available.  With OSCORE, that is the security context. As part of the registration operation, that information is stored along with the registration resource. The RD MUST accept all registrations whose registration resource is not already active, as long as they are made using a security layer supported by the RD. Any operation on a registration resource, including registrations that lead to an existing registration resource, MUST be rejected by the RD unless all the stored information is found in the new request's credentials. Note that even though subject names are compared in this policy, they are never directly compared to endpoint names, and an endpoint can not expect to "own" any particular endpoint name outside of an active registration - even if a certificate says so.  It is an accepted shortcoming of this approach that the endpoint has no indication of whether the RD remembers it by its subject name or public key; recognition by subject happens on a best-effort base (given the RD may not recognize any authority).  Clients MUST be prepared to pick a different endpoint name when rejected by the RD initially or after a change in their credentials; picking an endpoint name as per arbitrary-ep is an easy option for that. For this policy to be usable without configuration, clients should not set a sector name in their registrations.  An RD can set a default sector name for registrations accepted under this policy, which is useful especially in a segmented setup where different policies apply to different sectors. </ins> 8. The security considerations as described in Section 5 of RFC8288 and

Discussion:
Closes: URL
I'd appreciate a pair of eyes on this before tomorrow's interim, given my was flawed in several respects, and I'm not sure I got all the fixes right.
A question to be raised today is whether this should contain a note that where one wants endpoint names from certificates ("the other proposal" from ), they can write it up per application or make a short document of it.
Looking into the COSE!=CWT more deeply, I now think that they are not even mutually exclusive (TLS X.509 client certificate with SubjectAltName and a CWT posted to /token with a subj claim? TLS with CWT as certificate, and an X.509 posted to token? Reminds me of IP-over-DNS-over-HTTP-over-QUIC. Not that I'd do that...), so I'll send this through one more iteration that just takes the bag of all found (subject, authority) claims and requires them. Might make phrasing it easier, even.
From Ben's review DISCUSS at : There's two contenders for such a model: first-come-first-served with concrete guidance on what suffices for later updates fixed ep names The former is what I prefer (because I see the latter as a more niche application in tightly managed setups, whereas the former has the general application of providing discoverability without multicast), the latter is simpler. I'm starting work on a text for the first-come-first-served for tomorrow's interim.
Also playing in here from :
Quick scribble of a proposal in keywords: RDs remember information about a device for at least the active lifetime, preferably longer (but without obligation). The information they remember is the generally the most abstract they can be confident to represent the single device. Device authenticates with... DTLS without client authentication: Same (or resumed) session DTLS with self-signed certificate: Same certificate (by fingerprint) DTLS with certs that chain to a host name (with input from URL) if they're valid to authenticate as a server: Same host name (independent of chain) OSCORE from ace-oscore-profile: Same token (Does that even make sense? Is there any generic claim about client identity that can be in there?) OSCORE from LAKE with referenced certificate: as in DTLS OSCORE from LAKE with RPK: Same RPK Clients must register without sector.

RD may put them into a sector of a configured name.
for ACE: subject claim (or having the same PSK or possibly signed CWT identifier)
Hostname or subject identifier; if it does not exist: go for the public key. Thanks for the updates in the -26; they help a lot. I'm particularly happy to see the (default/example) "first-come-first-remembered" policy in § 7.5, which does a good job of documenting its properties (including potential deficiencies) and can be usable for many environments.  (I do have some suggestions for improvements to the specific wording in the section-by-section comments, but on the whole I like it.) It does lead in to a more general comment, though (which is not exactly new to the changes in the -26 though it is reflected in several of them): some aspects of the concept of "authorization" to appear in a directory, and the verification of authorization for the entire flow from client locating the RD server to final request at the discovered resource, are somewhat subtle.  (The new text discusses, e.g., "repeat the URI discovery step at the /.well-known/core resource of the indicated host to obtain the resource type information from an authorized source" and "a straightforward way to verify [discovered information] is to request it again from an authorized server, typically the one that hosts the target resource".)  The aspects I'm concerned about are not matters of a resource server being authorized to publish to a directory or a client deeming that a server is authorized to act as an RD (though both of those are also important), but seems to rather just be relating to the RD faithfully disseminating the information the RD retrieved from /.well-known/core discovery on the given server(s) (or otherwise learned via some other mechanism). In this sense the RD is just acting as a cache or efficiency aid, but the authoritative source of the information remains (in general) the server hosting the resource.  To be clear, I think the procedures that this document specifies are good and correct procedures for a client to perform, I'm just not sure whether "authorized" is the right term in these cases; "authoritative" might be more appropriate, in that the operation in question is to verify the information retrieved from the RD (which acts in some sense as an intermediary) at the more authoritative source.

(On a tangent from that note, it seems that there is not necessarily any indication to a client that a server claiming to provide a given resource (whether discovered via RD or /.well-known/core) is actually authorized to provide such a resource and be trusted by the client.  But that's not really a property of RD, and rather the underlying CoRE mechanism and any provisioned trust database, so my thoughts about it seem out of scope for this document.) (It's not entirely clear to me what the reader is expected to do with the information about the previous formulation.) (It seems that something also needs to cause the RD to check the authorization of lookup clients to receive the information in question, which might be worth reiterating in this section.) I'm pretty sure the intent here is that only the subject names that are certified by the recognized authority(ies) are stored, in which case I'd suggest to s/all those/all such/. (I can understand why the "store the whole list" logic is used, though there may be some subtleties about name constraints on the (X.509) CAs used, which is why we typically don't recomment treating the entire list of names in the certificate as validated from a single operation, instead preferring "is this certificate authenticated for this specific name?" when the specific target name is available.) Should we talk about whether the lifetime of registration entries is related to the various lifetimes of these credentials/identifiers?  DTLS without resumption is perhaps an interesting case, in that keeping the DTLS association "live" just to be able to update the registration information seems impractical, so perhaps some fixed cap would be applied on the lifetime in that case.  If resumption is used, the resumption information (ticket or session state) has some finite lifetime that could be used to bound the lifetime of the registration. IIRC an OSCORE security context can also have an expiration time; certificates and JWT/CWT have expiration time as well (though the procedures in the first bullet point would effectively allow a "renewal" operation), but the validity period (if any) of a raw public key would have to be provisioned along with that key (or just have RPK be handled akin to DTLS without resumption, I guess). (Similar to my earlier parenthetical comment, the requirement for exact match of all subject name information is unusual.

In effect this is a way of pinning the set of names that the CA has chosen to include in a single certificate, which is arguably a stronger requirement than needed but should not lead to any unauthorized access.)
Thanks for addressing my DISCUSS and COMMENT feedback