Change:
Remove speculation about how in detail ACE scopes are obtained. <ins> Security policies: The First-Come-First-Remembered policy is added as an example and a potential default behavior. </ins> changes from -24 to -25 Large rework of section 7 (Security policies)

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