Skip to Content.
Sympa Menu

edugain-discuss - Re: [eduGAIN-discuss] R&S and Proxy IdP/SP

edugain-discuss AT lists.geant.org

Subject: An open discussion list for topics related to the eduGAIN interfederation service.

List archive

Re: [eduGAIN-discuss] R&S and Proxy IdP/SP


Chronological Thread 
  • From: Jan Oppolzer <jan.oppolzer AT cesnet.cz>
  • To: edugain-discuss AT lists.geant.org
  • Subject: Re: [eduGAIN-discuss] R&S and Proxy IdP/SP
  • Date: Thu, 1 Jun 2017 07:13:34 +0200
  • Authentication-results: prod-mail.geant.net (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz
  • Organization: CESNET

Hi guys,

thank you all for your replies.

Jan

On Wed, May 31, 2017 at 01:22:51PM +0200, Wolfgang Pempe wrote:
> some of the issues mentioned below are being addressed by the Snctfi
> framework, cf.
> https://aarc-project.eu/wp-content/uploads/2017/05/AARC-Deliverable-DNA3.4-final.pdf
>
> Am 31.05.2017 um 12:59 schrieb Niels van Dijk:
> > As far as I am aware there is nothing in the spec that says that you
> > cannot. However, the owner/operator of that proxy *must* uphold R&S
> > regardless what the services behind the proxy are doing. Typically one
> > would need to lay out the exact or at least similar rules as described
> > in R&S to any of the parties behind the proxy. Another thing which might
> > help is if the proxy is not 1 entity(id) for all of the services, but
> > exposes a specific entity for each connected service in metadata. In
> > that way the individual services behind the proxy could signal R&S
> > compliance. Bottom line I think is that your fellow fed ops trust you to
> > make a judgement call on if you feel you can indeed allow the proxu to
> > carry R&S on the metadata you publish.

--
Jan Oppolzer <jan.oppolzer AT cesnet.cz>
AAI @ CESNET, <https://www.cesnet.cz/>

Attachment: smime.p7s
Description: S/MIME cryptographic signature



  • Re: [eduGAIN-discuss] R&S and Proxy IdP/SP, Jan Oppolzer, 06/01/2017

Archive powered by MHonArc 2.6.19.

Top of Page