You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: IETF-RFC.md
+27-22Lines changed: 27 additions & 22 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -153,27 +153,7 @@ Since the Invite Flow does not require either Party to type or remember the `use
153
153
154
154
Also, a different `userID` could be given out to each contact, to avoid correlation of identities.
155
155
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.
177
157
178
158
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.
The first step would be to confirm the validity of each properties:
610
590
@@ -640,6 +620,31 @@ Following the validation of the signature, the host should also confirm the vali
640
620
641
621
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.
642
622
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
+
643
648
# Acknowledgements
644
649
645
650
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