...
- Federation Participant Domain Use Policy DRAFT
- Federation Participant Domain Use Policy FINAL v1.0 (with updates from comments from this consultation)
...
Number | Current Text | Proposed Text / Query / Suggestion | Proposer | +1 (add your name here if you agree with the proposal) | Action (please leave this column blank) |
|---|---|---|---|---|---|
| 1 | Domains must be controlled by the registrar | A service must be operated by or on behalf of the registrar, but may be hosted in an arbitrary domain, with InCommon performing vetting replacing the DCV/WHOIS system of today | Nate Klingenstein (California State University) | Marcus Mizushima (California State University, Office of the Chancellor) | The new policy says: "Demonstration that a domain name is under the control of an InCommon Participant." which should meet this need. |
| 2 | "securely communicated to Participant" | is it worth covering what mechanisms are proposed? (and if the nonce is to be on a known record/URL or published in DNS why does there need to be a secure channel? | Alan Buxey (MyUNiDAYS Ltd.) | The word 'securely' has been removed from the updated text. Regarding specific methods, we did not want to lay those out in policy, but rather in our process documentation which will be built based upon this policy and may change over time. | |
| 3 | "...at the requested DNS name (A or AAAA record)" | There are valid use cases where the InCommon Participant owns/controls the domain but uses CNAMEs to direct traffic to infrastructure operated by other organizations on behalf of the InCommon Participant. The restriction requiring A or AAAA records should be removed. | Scott Koranda (LIGO) | Patrick Radtke (Cirrus Identity) | Updated to remove the requirement for specific DNS record types. |
See Also