Draft: draft-ietf-core-resource-directory

Commentary: Closes : 
 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  '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 ) 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 .  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 .
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
As part of the registration operation, that information is stored
along with the registration resource.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
The First-Come-First-Remembered policy is added as an example
and a potential default behavior.