Trust and Internet Identity Meeting Europe
5-6 Feb 2018: Workshops and Tutorials
7-8 Feb 2018: Unconference

Session 25 Baseline expectations of trust and federation

(Thomas Barton)

https://spaces.internet2.edu/download/attachments/9185/Baseline%20Expectations%20for%20Trust%20in%20Federation-Final-Sept30-2016.pdf?version=1&modificationDate=1475678790932&api=v2, we are discussing this document.

People are discussing how the can have a basic level of trust.

Baseline Expectations of Identity Providers (in the document)

Would you agree that you expectations in ID-Federation and EduGain. How close do they align and what are the differences?

It is the user-interface-metadata.

Privacy-policy only for IDP as a Service or for an organization?

Not all who have agreed on the statements meant the same things.

Those institution do not use their IDP with their own stuff.

There are only contact points (in this document-sector).

People only discussed baseline expectations, not implementation details.

One thing not listed: they should have a relationship behind this entities? It is coded in here, but not explicitly noted.

That IdP addresses all people in my organization.

It does not necessarily mean that that has the true representation or is just an imposter.Some links to work done in SURFnet and Switch previously on baselining and maturity scan methodologies

TNC presentation Eefje van der Harst (SURFnet)

[http://tnc2010.terena.org/schedule/presentations/show.php?pres\_id=28](http://tnc2010.terena.org/schedule/presentations/show.php?pres_id=28)

( [http://distance.ktu.lt/terena/6c-federations-technologies/eefje-van-der-harst-establishing-trust-professionalizing-identity-manage](http://distance.ktu.lt/terena/6c-federations-technologies/eefje-van-der-harst-establishing-trust-professionalizing-identity-manage) seems not to be working anymore ;( )

Thomas Lenggenhager (Switch)

[https://www.switch.ch/aai/support/presentations/opcom-201105/AAI-OpCom-IdM\_Maturity\_Scan.pdf](https://www.switch.ch/aai/support/presentations/opcom-201105/AAI-OpCom-IdM_Maturity_Scan.pdf)

Now: Baseline Expectations of Service Providers

No. 2: Whose permission? Is there an individual consent? That not necessarily would be true.

Who would recognize what is appropriate and inappropriate?

Keep in mind that this is Baseline.

Is the IdP-granting level.

It also depends on the setup. If a third-part is a data-controller or a data-processor for a data-controller in front of it.

The SP should not go beyond what the user primarily agreed on.

SP-proxy simply needs to write down what the purpose of the SP-proxy is. Then it does not need additional permissions than the ones already agreed on.

We don´t have a well-defined way in our federation to describe the purpose. In EduCare there at least is a document for that.

Every single IDP would have to look to the primarily made agreements.

Do we want to have this points in this document section processed?

What is the reason for no. 5?

How would that work? You may secretly discuss exchanging attributes. It is for the vended systems e.g. for universities who need that information.

They publish what they say they need. It is a transparency-thing.

This points are standing the expectations what they expect to be standing public.

An organization who wants to run an IdP wants it for a service.

Is it ok to do less than no. 5 than in your contract?

I am going to have number 5 revised.

Are there differences between no. 1 and 3?

I have wondered myself.

3 is about technical security.

1 also got risk management.

Would not be 1 be the general expectation for an IdP?

Service providers are the ones who are not trustworthy

There is a lack of parity between the two.

Case: If service provider cares about the privacy of the user, which is not taken care in this points. They might leak information to other individuals/companies/…

The Attribute-Authority is missing. Would behave similar to the IdP.

The document was not technological driven.

We have to update federation policies.

Section: Baseline of Expectations of Federation Operators

No 3 is about the metadata between all entities in the federation

No 4: Entity categories, this name may be changed in the future

What is no 5?

It is the new copy left

Could it work with other entities? Not the expectation to do that.

Federation to me is a community. That should be declared in the preamble.

How do the IdPs and SP actually meet the expectations?

The federation will have a clear role. Thomas is not going to responsible for all the security issues.

Major point: there is another authority: the other participants. We can have the community to resolve that.

Is dealing with naughty users a Baseline Expectation?

Who is the audience of this document?

This is for the community. But that is not the full answer. This points also have to be in the contracts for the participants.

Are we planning on publishing metadata?

Interesting question, not enough time to analyze, but the answer must be no. If yes, we are in the RNS, where it can´t be describing any real baseline.

Nick will summarize this discussion in the summary session.