Skip to content

Commit 81e3a56

Browse files
committed
Moved Directory Service spec to appendix
1 parent fc120ee commit 81e3a56

File tree

1 file changed

+27
-22
lines changed

1 file changed

+27
-22
lines changed

IETF-RFC.md

Lines changed: 27 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -153,27 +153,7 @@ Since the Invite Flow does not require either Party to type or remember the `use
153153

154154
Also, a different `userID` could be given out to each contact, to avoid correlation of identities.
155155

156-
If the Invite Sender OCM Server implements a WAYF Page, such a page MAY include a fixed list of servers, in addition to, or instead of, a free-text input where any OCM Server can be entered. This is especially useful if the Invite Sender is part of a federation of associated OCM Servers. In order to populate the list of associated OCM Servers, the Invite Sender's server MAY make use of a Directory Service: in that case, the Directory Service MUST expose, via anonymous HTTP GET, a JSON document with the following format:
157-
* REQUIRED: `federation` - a human-readable name for the list of OCM Servers exposed by the Directory Service
158-
* REQUIRED: `servers` - a JSON array of objects to describe the list of OCM Servers with the following string fields:
159-
* REQUIRED: `url` - the OCM Server's FQDN
160-
* REQUIRED: `displayName` - a human-readable name for the OCM Server
161-
Example:
162-
```json
163-
{
164-
"federation" : "The ScienceMesh Directory",
165-
"servers" : [
166-
{
167-
"url" : "https://ocm-server-1.fqdn",
168-
"displayName" : "OCM Server 1"
169-
},
170-
{
171-
"url" : "https://ocm-server-2.fqdn",
172-
"displayName" : "OCM Server 2"
173-
}
174-
]
175-
}
176-
```
156+
If the Invite Sender OCM Server implements a WAYF Page, such a page MAY include a fixed list of servers, in addition to, or instead of, a free-text input where any OCM Server can be entered. This is especially useful if the Invite Sender is part of a federation of associated OCM Servers. In order to populate the list of associated OCM Servers, the Invite Sender's server MAY make use of a Directory Service, which is expected to follow the specification detailed in Appendix C.
177157

178158
Implementors that provide a WAYF Page SHOULD make the URL for the API endpoint of such a Directory Service configurable, allowing the OCM Server to be part of a network of associated OCM Servers. The configuration mechanism MAY allow an OCM Server to be part of multiple networks, thus displaying a union of multiple lists in its WAYF Page.
179159

@@ -604,7 +584,7 @@ signature = {
604584
headers['Signature'] = format_signature(signature)
605585
~~~~~
606586

607-
### How to confirm Signature on incoming request
587+
## How to confirm Signature on incoming request
608588

609589
The first step would be to confirm the validity of each properties:
610590

@@ -640,6 +620,31 @@ Following the validation of the signature, the host should also confirm the vali
640620

641621
As an example, if the payload is about initiating a new share the file owner has to be an account from the instance at the origin of the request.
642622

623+
# Appendix C: Directory Service
624+
625+
A third-party Directory Service is a back-end service used to federate multiple OCM Servers and facilitate the Invite flow. It is expected to expose, via anonymous HTTP GET, a JSON document with the following format:
626+
* REQUIRED: `federation` - a human-readable name for the list of OCM Servers exposed by the Directory Service
627+
* REQUIRED: `servers` - a JSON array of objects to describe the list of OCM Servers with the following string fields:
628+
* REQUIRED: `url` - the OCM Server's FQDN
629+
* REQUIRED: `displayName` - a human-readable name for the OCM Server
630+
Example:
631+
```json
632+
{
633+
"federation" : "The ScienceMesh Directory",
634+
"servers" : [
635+
{
636+
"url" : "https://ocm-server-1.fqdn",
637+
"displayName" : "OCM Server 1"
638+
},
639+
{
640+
"url" : "https://ocm-server-2.fqdn",
641+
"displayName" : "OCM Server 2"
642+
}
643+
]
644+
}
645+
```
646+
647+
643648
# Acknowledgements
644649

645650
Our deepest thanks and appreciation go to the people who started the work on what would become this specification in 2015. In particular we want to thank (in alphabetical order) Guido Aben, Russell Albert, Holger Angenent, David Antoš, Hrachya Astsatryan, Kurt Bauer, Charles du Jeu, Andreas Eckey, David Gillard, Andranik Hayrapetyan Wahi, Christoph Herzog, David Jericho, Frank Karlitschek, Christian Kracher, Ralph Krimmel, Massimo Lamanna, Simon Leinen, Jari Miettinen, Jakub Moscicki, Frederik Orellana, Vlad Roman, Christian Schmitz, Woojin Seok, Rogier Spoor, Christian Sprajc, Peter Szegedi, Ron Trompert, Benedikt Wegmann and Johnatan Xu.

0 commit comments

Comments
 (0)