European Workshop on Trust & Identity

In cooperation with GeantLogo184x80

December 2nd

Session 19 <Federated Registries > (14:15/Room K7)

Convener: Richard O`Brien

Abstract: End users, developers, and automated processes deal with persistently identified, self-explaining digital objects which are securely & redundantly managed & stored in the Internet which is an overlay on existing or future information storage systems.

The Digital Object Cloud, as envisaged with Greenlist Federated Registries supplying discovery & verification of Digital Objects indexed in the Handle System and used in the DOI System as a component.

Tags: Identifier, Digital Objects

Notes

To orient this I am going to talk about a use case that we presented to the ITU about 18 months ago, and the one use case that we are focusing on is for the people that own accounts, private or company ones. We are looking at the problem of the unprivileged people that don’t have bank accounts but have prepaid cell phone accounts. If they were able to live in the electronic economy, we wouldn’t have the situation today where 70% of the people don’t have a bank account. This is one of those development areas of the economic Internet… We want to prevent wasting capital where there is too much imbalance of fee processing and other kinds of cash resources from one jurisdiction to another. This continues to exist today so the illustrative use case shows how it works, the payor identified to the account, he gives a name of a person to send money to, and the portal queries Greenlist, which obtains Virtual Identifier (VID) to match and Linked Credit Account (LCA) number, it can be an ACH, BIC/IBAN or debit card for example.

A payor verifies if the payment is correct and the objective is to send an irrecoverable payment to a destination that has to be trusted. It’s a payee address that needs to be certified as accurate. It’s a proof that if you send money to that location that it’s going to go to the person that you want to send it to.

The teachers can dispense rewards, we want to teach the children in the city that if you just do your homework to get some payments, it’s more efficient where the parents can actually learn from their children and there is no merchant fraud risk as the payments happen instantly, and there is a human capital growth involves local businesses and narrows the digital divide.

The idea is to show that the teachers are allowed to a system of rewards and getting achievements. The point is to have digital objects to bind entities. We are terribly involved in smart contract work so we talk about digital objects, thinking in terms of registering, to have this container, to self-describe and the access control can be shown on a database level.

Handle System is a distributed, open-sourced, deployed Digital Object Network Architecture and potentially can bind a pseudonymous name (via x.509 certificate) to every identifier of which bank provided an account for every student.

The economics are sustainable - in the first year a lot of tablets were bought because of this system. And then the other part of this is the way we have mapping public identifiers and the 9 data points about account owners, and when to draw the money from the account is never given. Student enrols in the bank and the teachers enrol as the authorized payors to distribute funds and all of the regulations are conformed in the cloud, there is access control which is given by a bank to the cloud and we can have analytics who made most money etc. And if the student moves to a different state, that can still be used without having to reregister.

DONA – Digital Object Network Architecture

This is a same kind of standards process which brought the Internet into existence.

In the US we have two very powerful service providers that do the back-office accounting for small and medium-sized banks and there are about ten banks that do the majority of credit-card processing in the US.

In their world, if someone was to create new accounts that could just be synced using todays infrastructure. In different industries there could be the need for syncing for different types of services.

The problem that we have to address is the need to have maintenance of trust even when there is not a perfect syncing. There is a way to see if the query is to a trusted registry, and there can be something in that registry that is out of sync and if you are using that query to move money and what we developed is to use multicast round robin is when one does a query to make a multicast sync to alert all registries where they would refresh.

If something goes wrong, there will be a report back that some packets are missing. If there was an outage and no packets are sent, and the central doesn’t know if it’s in sync at all, so the timer in the overall system

That directs the queries starts to tick and that maybe out of sync can occur for 24 hours, so you just have to determine the window that’s acceptable.

By definition the window of recovery only has to be less than the recovery window(?). The big banks are trust worthy because of their reputation, oracle databases. And that’s the world today. Of the Internet and the fintec regulators and we will have systems that sync in those worlds. The new system is different and if you prove the trust with math it’s still better than just verifications. Money is only when it can be withdrawn with cash.

The conclusion is that we should have a hybrid legacy (traditional database) and next generation (block chain, etc.) synchronization standard.

Session 18 <Mapping Eduperson to OIDC claims> (14:15/Room K6)

Convener: Jim Basney

Abstract: Mapping EduPerson to OICD claims

Tags: Attributes, OIDC

Notes

Presentation of the attribute values of EduPerson and identifier properties. Discussion on so called "orphans" (that have been created but have no place in the OICD connect place).

  1. 1.Attribute values
  • Explanation of the open document (http://goo.gl/ryIqL3), definition of the terms (given_name, family_name etc.)
  • Discussion of the definition / possibility to define the term "middle_name"
  • Discussion of the definition / possibility to define the term "name" (what it could mean), basically you could put anything there
  • profile: URL with some proper information of the user
  • picture: jpegPhoto, give info about race, gender, religion, typically problematic for IP to release -- (no) good match here (comparison of US, Austria - publishing law, data protection law)
  • website (user is affiliated to), gender, birthdate (nothing in eduperson space either, very sensitive in perspective of data protection)
  • zoneinfo (info about where you live, or time zone)
  • locale (preferred language)
  • address
  • updated_at (doesn't tell about the updated sessions of the user - recent updated, total updated? ; session time out, a lot of possibilities what we could put in there)
  • email
  • email_verified (basically says that in some way between RP and OP there is an agreement of what verified means, in our case we could use this, maybe we could decide to consider an institutional email address to be verified)
  • can be defined in any way we like
  • i.e. university account, institutional email address
  • Address; what exactly to put in? Personal address, office address, institutional address/department address?
  • Phone - home/office - which number?
  • phone verified - proposal: if it was provided by the IDP it is verified


Short Q&A:

  • Single valued? - No, almost all are multi-valued.
  • Phone value? – International.
  • Street name? - depends on the place.
  • Preferred user name? - Greens: mostly in common use, which is good for this case.

  1. 2.Identifier
  • identifier properties / explanation of the table


I’ve assumed that we will not support a scenario, technically we would need a proxy to beach from a to b.

What are the mechanics?

  1. You provide a URL, then you’ll find a list of names etc.

You must be sure that you are giving the same proxy?

Looking at the 4 scenarios that we have, explanation

(table MAPPING SAML -> OICD PUBLIC SUB CLAIM...)

(table MAPPING SAML -> OICD PAIRWISE SUB CLAIM...)

(table MAPPING OICD pairwise sub claim -> SAML: What SAML identifiers can be create from an OICD pain

  1. 2. "orphans" - have been created but have no place in the OICD connect place

Discussion on terms:

  • eduPersonPrimaryAffiliation
  • (organizationName)
  • eduPersonAssurance


Given that number of red ones, which we must have, especially:

  1. eduPersonAffiliation
  2. eduPersonScope
  3. ?? XXX


How to do that?

JSON Web Token (JWT)

OpenID Connect does not specify cardinality, which may limit ability to map OIDC name to eduPerson name if the latter one specifies a single valued attribute.

Session 17 <Privacy by Design in Federated Identity Management (FIM) + State of the art of PbD> (14:415/Room K2) – NO NOTES

Convener: Berit Skjernaa

Abstract: FIM, while solving important problems of remote entity authentication, introduces new privacy risks, like new possibilities of linking private data sets and new opportunities for user profiling. We will discuss privacy by design requirements, transpose them into specific architectural requirementsand and evaluate a number of FIM models that have been proposed to mitigate these risks.

Tags: Privacy by Design

Notes

We are currently making a survey regarding the adoption of Privacy by Design in Danish companies for the Danish Business Authority and would like input to what the status is throughout Europe, what are the obstacles, what are the commercial benefits, who does a good job, and what is and can be done to push the adoption.

What are the incentives and why is privacy... I would come to the conclusion to think about things like privacy in the systems we are building.

I would like to show you what we found out privacy and privacy by design means in particularly in the field of identity management. 

From general provision reduced to requirements for identity systems. 

Privacy risks related to FM, linkability and observability as two general problems, linkability is that basically two SPs should not be able to know that they are dealing with the same IDP. The worst thing to do is to make join identifiers. 

Session 16 <Cooperation of open source identity management products> (14:15/Room K1)

Convener: Igor Farinic

Abstract:How to make it possible to integrate indentity management source from different space for costumers?

Tags: Open source

Notes

Working group.

The idea behind the product:

  • Identity eco-system, something like a marketing place to increase innovation, re-assure some revenues.
  • Developing an open source identity management tool.
  • Evolved to something we call eco-system


The basic idea is to be open-source. So it's like an alternative tool.

Describe the first steps:

  • some guidelines
  • spread the idea: more members


TIER
- similar idea

"We are trying to do it for enterprises as well"

Internet2 TIER http://www.internet2.edu/vision-initiatives/initiatives/trust-identity-education-research/

Missing provision capability

Most important:

  • Ideas- smaller projects cooperate together.
  • Integration between two projects?


Spherical cow group
– well connected to TIER.

"When you're sitting here you are providing very good software.

Different aspect to this.

How the customers will see this? Not only companies but the individuals as well.

CAS?

Open id connector, vendors support the project. There is no point of projects joining the eco-system.

Important: promise.

Most companies are promising that we'll make it work together.

Too many combinations in different projects to test out every combination.

Initiatives such as TIER? The idea behind it and the motivation is a different one.

Provide the best open-source experience ever!

TIER- sustainable funding to keep the project going; identity management stack?

Different sustainability- small company, getting money from customers to get bugs fixed.

Common aim:  

  • Open source to work as good as possible
  • Each project working on its own but the idea is cooperation.
  • Eco-system of pieces that work together.


The TIER group can become a member of the Eco-system/group.

Q: What's the path/pattern? To branding?

A: Providing an STML.

Most of the projects are not really TIER related.

Session 15 <Identity for Everything> (13:30/Room K7)

Conveners: Floris Kleemans, Johan Saton

Abstract: Establishment of a an Open Registry called DENARS which would be used for registering and collecting entities to be used all around the world in different kinds of applications and an Identity Layer should be had on top of the Application layer.
Also the exchange protocol of grouping all the entities for a specific transaction named UETP.

Tags: Architecture, Digital Objects, IoT

Notes

We would like to get a clear conclusion out of this session and it’s good to phrase the challenge and that is do we need an identity or the entity layer in the internet architecture, if we have an identity for everything is it something that we actually need?

Open source initiative - what we felt is that if we want to connect the people, how do we connect it, and if we take a look digitally all these entities, that reside in an application environment, a natural language environment. How do we connect it??

We felt that if we can start working with social economic entities we can connect them automatically with each other would that solve problems and that’s how we came to make a new language, Uniform.

This happened fast, in 2014 to establish this foundation, to facilitate development of UETP, free to use by society to connect all these things together.

The internet itself is fragmented, we have government on one side, which e.g. said that the personal data of European people is not allowed to be stored in US based clouds anymore. If we want to have an automatic connection we felt like to come up with an architecture. Identifying the university, with the unique ID, the second step that we do it to create meaning around it, virtual product e.g. and that you bring together to get an economic transaction.

We felt if the economic Internet works we need three things, connectivity, to create understanding, we need a semantics layer, and when there is understanding we need interaction, to identify.

Analogy: Knowledge model for business transactions like Wikipedia for some common domains.

Taken from the RFC 4122 unique IDs we added some features to it, what we then do is when you have the ID you create meaning and what you create with the UETP is to provide semantics and methodologies and we need a language for that The development model for the protocol is a open knowledge model like Wikipedia and if want to add different things that’s possible.

You can have a similar registry as we have for DNS and IP addresses, we would be able to create something similar that we can manage at that level. Who is able to see access and manage this identity of entity?

We have all these interfaces and APIs and the great thing is that you create this ID and make whatever you want and if it’s important to you it can be done with it. And it can be done offline, decentralized, a new kind of DNS system occurs. Because we start managing a transaction and any context.... We have all kinds of internal communication in this chat, where people say "I want to share this with you" to someone else.

Such entity registry can be linked and electronic devices when they do a transaction, when entities how entities and what entities have a space configuration and this is what you can provide to someone whomever you want to provide.

Link up multiple transactions (webshop, payment, delivery, etc.) in a single transcript with a common model. (N-party groupchat)

We have this information what would it be in the transaction, we put it in the group chat, and that is how we would process the transaction, and when it comes to trust, there are trust dialogues where you can share things with someone that you want that you trust. Sometimes there is legal requirement but this is the way how you can bring it together.

Richard O'Brian:

I see value in having entities that are not necessarily individuals but have functions or smart programmes, they would have a source which if its open you can see how many hands touched it. That’s my 2 cents, we need that at the stage as there is too much lack of attention on software integrity.

Rainer:

On the identity layer I see this as a cool thing. We can start working out processes on identity related metadata challenges, but somehow the thing is merging entities in the sense of organisations and devices in a much more general identity layer. I find it hard to see how you could have this generic identity level (that is a kind of abstract root object in OO-programming speak) from which derives anything, whereas identity management requires very specific properties, e.g. keys. I fail to see the potential of linking up the two levels of abstraction.

Floris:

That’s how we made the different in who entities and what entities. The entity search that starts blank can turn into anything, it’s just a unique identifiable thing vs. whatever and then we can set what kind of functionality of capabilities, and see how to bring it into the identity level.

One of the cases in the internet of cargo where the cargo itself becomes smart, it knows its position and logistical options and when it transports it checks in which direction it would be the best to go. There needs to be interaction and that kind of data centricity doesn’t exist.

If you have shipping containers, there are a lot of them which aren’t used, and one of them is your container that you can communicate to. My question is: can I use a container for a quick transport because I really need a container here and now, so instead of all the paperwork we can address a container itself.

In the transaction all of the parties that are involved there are also those included to show you who has to be a part of it. If you need to use a container for example to transfer something from Netherlands to Germany, all kinds of organizations need to be legally included.

Q.: In your model there are n to m transactions possible, and the rules are very difficult to make, which transactions are allowed and which aren’t, and I think it might be complex and then you have benefit when you have done this setup and therefore I think that when the transaction scenario is simple this model might be too big that if you have a complex one, your model might a better choice for this if you do the design with this model for a quite complex scenario.

Johan: That’s also the scenario that if you want to create a protocol, not to only checking whether it works or not so we have a quite big set of different use cases of even the small ones and the big ones and we have to see what we can learn from it, what works and what doesn’t. What if we can use a protocol for entities to communicate and implementing that into your specific transactions?

Floris: You can make this as simple and complicated as you want, if you want it simple just do it 1 on 1 as communication. You can add as much knowledge as you want. And if the fiscal entities want to include themselves in the code, there is something that needs to be done.

Q: Does an identity layer add complexity?

A road sign, would having this entity layer would help you establish a use case to make it international?

Floris: We are setting it up for global, Singapore banking, Australia... Different use cases. The first live eco systems are in the Netherlands.

Johan: The use cases have to be sponsored by different companies. We have a lot of people who want to import a car, and you have in Netherlands e.g. the BMP tax you have to pay when you import cars, which is an extremely big hassle. This would be a great use case for the group chat.

Rainer: Two ways to include into the Meta model: One is the way how we do the metadata and the other way around is what kind of existing protocols can be integrated into your existing schema?

Floris: PKI structure and some of the other and we have to go in more depth in the knowledge model.

Albrecht: Individual object can have a very long lifetime and the protocols that you want to employ in between two parties and this reminds me of setting up a protocol and people won’t use it anymore as students aren’t taught to use it. What do you envision if the lifetime of an object is much longer of the technology cycle?

Floris: It will be restored in a certain time, and we can’t create a solution after but you can see this as a domain name if you don’t extend. Maybe you want to include it in a different system in the future and that is also possible.

We can’t have too many nodes as the scalability problems would arise. Obviously people in whatever thing we, don’t see it as a programme but Wikipedia. And as long as we remain open for users, that it can grow on top of it but of course people can make it great and this is basically more community management than anything else and the best changes are to keep it well so we have that.

Session 14 <OIDC federation> (13:30/Room K6)

Convener: Roland Hedberg

Abstract: Discussion of two mayor problems connected to the issue: client registration and reliance on the WEB PKI.

Tags: OIDC, federation

Notes

2 major problems:

1st Problem- Client registration (it is either completely static, or it is dynamic)

  • Dynamic: you're registering someone you don't know anything about
  • You want to be somewhere in between dynamic and static -- how would you do that?


SOFTWARE STATEMENT (SS)

The owner of the RP sends some necessary client information and key information, what happens is that the owner sends this information to the federation who signs it and sends it back, so when the RP does a client registration it includes the software statement and the OP can check if it’s correct.

  • This would place you somewhere between static and dynamic; you could also imagine that the owner is a big company and by using SS can spin up as many RP as they want.
  • Appealing: would be easy for relying party to start up in a B2B way, - could it be signed by different federations as well? - Yes
  • RP and OP have to trust each other? - Yes - the same mechanism works for both RP and OP
  • How could login procedure look like - fed A logs in to fed B? - this is still in the conveners head, we haven't tried it yet.


Thought about approach of one file that lists all participant of federation?

  • Discussed in the Kantara OTTO working group, there is a discovery protocol where you do that, connecting, it is basically asked on the user entering some kind of identifier
  • Federation could also collect these kind of information, has some kind of interface (MDX) for distributing the information.
  • Federation must have a relationship to every RP and OP it will sign a SS.


Next steps, going to work with open ID foundation and other standards bodies?

- Yes, this idea is based on one RFC, a couple of existing internet-drafts. But we will also have to write some new specifications that probably will be submitted to IETF

2nd Problem - reliance on the WEB PKI

Now you go to web pages and you have to trust the certificates and the SSL software.

Question to get rid of PKI? -- No solution, if this is broken than everything is.

  • Now you go to URL and behind is that JSON document
  • Instead: URL and you get JWS, signed document
  • That ID that I have, again we use the software statement


Q: Would be similar for how it is today?

  • Yes, it's all in the details, but pretty simple, you could use FTP/email for distribution of the information because you could verify the signature.
  • Discussions: when you publish this parameter jwt url, we have to add a new parameter jwt urlsign.


Q: Outside of fed, it wouldn’t make much sense?

Given that you have these 2 options, we also would have to have something that singles that (jwt urlsign).

Google as a fed by itself, probably they could use that as well?

- Legal, standard documents

I’d like someone to look at it (participants from EWTI), also maybe use it in their federations

Would be easy for some feds today, cause there is SAML IDP/SP fed today u can set up these proxy, u can start testing these things (ie. mobile applications, getting a specific OP software)

Q: Where to find all the software statements?

- A group is working with mobile operators, and they have a similar idea / were all allowed to talk to the mobile operator / telephone as an RP, u can use any machine as an RP

Q: Is there any kind of filter?

- 3 different telephone numbers connected to one person (i.e. 3 different SIM card, you cannot go by the information alone, you still have to do authentication.

Concern: data protection?

   - You don’t have to use it, if you don’t want to. There is no standard way for doing it otherwise.

Q: MDX already running, you could leverage that infrastructure to do discovery that isn't based on email or ePPN.

- Yes ... you would need to add some query parameters to query on IDP displayName, entity category support, etc. (talk to Ian Young about this)

Q: Would work only for limited number of IDPs?

- no, but we may see a collapse of feds, we'll see more fed's / if this system allows for more dynamics, people with same interest will be constructing more of these fed's

Q: Is it sustainable, where federations connect at the same time?

- When you look at the policies behind fed, they are not going to change that.

Should consider talking to Marina (GÉANT Federation as a Service) and Janusz from HeaNet about getting support for this into Jagger, and then into FaaS to kind of slipstream support into the community.

Q: did u already experiment with open ID connect code?

A: there isn’t software enough, we are still working on it.

- Participant: in University of Chicago, there was (we) made a successful testing unit

Solving the chicken-and-egg problem with trusting the key that signs the JSON software statement:

Use a private signing key that signs keys that actually sign the software statements, then you can do key rotation on the keys that are doing the direct software statement JWS.

Session 13 <eSignatures> (13:30/Room K3)

Convener: Pietu Pohjalainen

Abstract: Current EU legislation recognizes eSignatures and advanced eSignatures. The advanced eSignatures are in practice hard to use. In the 'normal' eSignature field, there's quite a lot of variation in what does it mean technically and organisationally.

Tags: eSignature, eIDAS

Notes

I'm having a project on gaining deeper understanding of what are the technical possibilities with online eSignature operators.

Interpreting EU-regulation on eSignatures is confusing.

An advanced electronic signature is one that fulfils the following four points:

  1. Is uniquely linked to the signatory
  2. Capable to identifying the signatory      
  3. Is created using means that the signatory has under his sole control
  4. Is able to detect any changes to the signed data


We discussed about the current usage problem patterns in using electronic signatures in practice. There is a number of eSignature operators, who operate in varied manners; especially the point #3 is a problematic for gaining an “advanced electronic signature” status for an outsourced operator.

The main problem seems to be the confusion in the field between all of the different “shades of grey”; the legislation distinguishes between three shades of grey:

  1. the normal electronic signature,
  2. The advanced electronic signature,
  3. The qualified electronic signature.


However, in each of these categories, there’s many ways of doing the signature, and we discussed that it would be beneficial to have more thorough understanding of the differences.

This would help utilizing organizations to choose between the trade-offs given by the technical features of different solutions and the cost required to deploy the solution.

The regular electronic signature can at its simplest form be just a postfix in an email, like:

“br, Pietu”, or an embedded .jpg file.

Obviously, it is not overly reliable way to identify the signatory, and is prone to falsification claims. It is clear that some kind of “regular” signature, that is backed up by a 2-factor authenticated session is more reliable. However, currently we don’t have very good understanding of distinguishing between the different ways of providing these signatures as a service.

In today’s web world, the connection between e.g. one’s smart card for doing advanced or qualified signatures was discussed to be “a mess”. In Finland, the government standard solution is to have specific software installed in every desktop, which clearly is not saleable to the web age. In Estonia, the government is supporting the development of web browser plugins, which gives citizens the technical means to do advances signatures, but the plugin mechanism still requires installations and historically has been proven to be a source of security problems. WebCrypto API is a way to expose the PKI certificate’s private key for cryptographic operations, but according to discussants, it seemed to be more targeted for performing DRM controls rather than digital signatures.

Manne presented a recent Nordic eID status document, which also discusses electronic signatures. One main points is that the currently written legislation is erroneously regarded as the minimum security level, while is should be considered as the highest level; in general there is no requirements (unless specifically noted) to request qualified signatures in digital operations.

a1: In Nordic eID Survey – 2015 (study initiated by the Nordic Council of Ministers) states:

"Unfortunately, many EU Member States have turned this principle inside out by stating that QES is the only mechanism that can replace a handwritten signature. The effect is in too many cases a preservation of the paper process, blocking alternative approaches that would be sufficiently secure (from a risk management viewpoint) and more user-friendly and efficient. While a handwritten signature is the only practical mechanism for proving consent on paper, many approaches can be used to prove a digital consent, and the choice of mechanism should be guided by a convenience and risk analysis rather than by blindly specifying a particular technological solution. This “QES only” approach can be viewed as contrary to the intention of eIDAS and the eSignature directive, which explicitly state that QES is a maximum level. There is no hindrance in eIDAS from accepting other forms of electronic signatures as long as the mechanism(s) used fulfil the purpose of the signature in the process. One may argue that AdES/AdESQC/QES should only be used when:

  1. There is a legal requirement for using the specific mechanism; as described above such requirements are too often posed by EU Member State laws and regulations without due justification of the real need.
  1. A risk analysis (typically by the owner of a digital service) yields a requirement for use of the mechanism, typically the need to collect a strong “proof”.
  1. The mechanism is right for the service by being suitable and user-friendly as a component of the process; this angle at AdESs is unfortunately rarely seen.


It is fair to say that the legal approach of always requiring QES may have a sound explanation in the legal systems of some of the Member States, e.g. there may be specific requirements (form factors) regarding what constitutes a legally valid document/agreement and/or what is acceptable as evidence in court. Thus, one sometimes sees the term “legally valid signature” used as an equivalent of QES; however this is clearly misleading since other electronic signatures surely carry legal value at least in those Member States that are not strict on QES requirements."

Peter (Peter Alterman, Ph.D Chief Operating Officer - SAFE-BioPharma Association (www.SAFE-BioPharma.org) presented us with the current, traditional knowledge of how to do e.g. PDF signature using standard Adobe technologies.

In the past, these required desktop installations, but it turned out that nowadays there seems to be also solutions that allow securely signing PDF documents through uploading the cloud.

There was an explanation of how the process goes so that although the signatory’s private key resides in the cloud, it is still under his sole control.

Thus, it was argued to be a qualified electronic signature, as the private key never leaves the HSM device in the cloud, and thus the signatory is the only one who can sign the document with his PIN code.

Conclusion

It might be good to have a group of people working on this issue and work on the risk assessment and make the risk assessment easy for the relying party to choose between the technical qualities of the signature and the associated cost.

The main problem seems to be that people - relying parties - are not aware of all the technical complexities and legal consequences of choosing one solution over another.

The insurance should come from relying party.

Can we have a cheaper, less advanced ways? - The risk assessment is a key to it.

Session 12 <Enhanced Privacy with Polymorphic Pseudonyms> (13:30/Room K2)

Convener:  Hans Harmannij

Abstract: Polymorphic pseudonyms can be used to solve several privacy problems, related to linking users across parties, including the identity provider, tracking Service Provider usage by the IDP, and tracking by a hub or proxy. At the same time it allows collaboration between specific SPs, and it allows switching IDPs by the user, while remaining known to SPs.

Tags: Pseudonymity, Unlinkability, Unobservability

Master thesis

Introduction: what are polymorphic pseudonyms?

Problems we face:

  • linking across parties
  • user tracking at ID provider
  • hub as privacy hotspot


Features:

  • collaborating service providers
  • switch identity providers


Homomorphic encryption: we can create a polymorphic pseudonyms(PP) and do adaptions to the data even though its encrypted.

A polymorphic pseudonym is general for the user.

  • PP then needs to be changed to an encrypted pseudonym (EP) for the service provider
  • 1st step: authority that distributes keys to all parties
  • IDP gives PP of the user, and the EntityID of the SP to a pseudonym facility
  • Pseudonym facility specializes it for that SP.
  • SP can decrypt it


PP and EP can be randomised which so they are unlinkable to earlier sessions with different copies of the same pseudonym. If you decrypt an EP, you get a random looking string which is different for diff service providers (but is the same for the service provider each time the user logs in there)

Demonstration: logging in to a service provider via shibboleth.

EP is different in different session, final pseudonym is the same at the same service provider.

Variations:

  1. Full mesh federation
  2. Instead of EP, a PP is passed to the hub, which acts as pseudonym provider
  • As most P are randomised, the hub can’t see which user it is -- not linked to each other
  • The hub may not provide services for itself
  1. Hide service provider (SP): Starting a request from service provider -> the hub encrypts the entityID of the SP with public key of the pseudonym facility. ID provider can’t see this.

Homomorphic encryption

System wide public key k (k...random value)

Conv. changed the public key with which it is encrypted by...? // changed general encryption

k, k', k'' are rand. Numbers.

PP = EG(uid, yk, k)

->

EG(uid, yk | SPid, k')

=

EG(uid, k', ysp)

->

EG(uid | SPid, ysp, k'')

=EP

aud1: how much information does the pseudonym facility get?

convener: not really any. ID provider contacts ps. fac. and it only sends a randomised PP; the pseudonym facility can't see anything about the user.

aud2: 'full mesh': encrypt P, then transferred to SP. why is that encryption necessary? Maybe to protect the value?

convener: to make sure the P is only really visible to the SP

aud3: where does this apply? Who would be interested in this?

convener: still looking if there are any better solutions. Also looking for ways to get rid of the database.

aud4: scenario: in primary education: you got a relation between a publisher and a publishing house. Need to send your data to both entities.

contract between publishing house and ...?, but they don't need to know each other

-Paper on this (NL)-

aud5: If a single user is enrolled by SP1 or 2, the collaboration space concerned doesn’t know it is the same person?

Diff SP work together - get same data.

aud6: if you have one of the P of the SP, you decrypt it --> get a random string back.

? - Encrypted parts are random.

aud7: Are there any obstacles in implementing this (?) from an organisational viewpoint?

Key management authority and Pseudonym facility needed, as extra parties. PF can be the same as the hub, then can’t be a SP. Organisational problem exists. Not a lot of technical problems.

convener: Possible to create polymorphic attributes that are suitable for all SP. but first need to be specialised for diff. parties.

__________________________________________________________

Links etc. will be shared via e-mail

Source code: https://github.com/polymorphic-pseudonyms

Paper by Eric Verheul about polymorphic pseudonyms in Dutch education, containing all technical details: http://www.cs.ru.nl/E.Verheul/papers/PP2/PEKScheme.pdf

Session 11 <Self-Assessment Tool Requirements Gathering> (13:30/Room K1)

Convener: David Groep, Hannah Short

Abstract: Useful and feasible assurance can be promoted by transparency. Assessing compliance based on formal audits poses barriers for many organisations. Alternatively, transparent self-assessment, like peer review, can also give sufficient trust but in distributed systems it doesn't scale without automation. We propose to explore these topics and brainstorm about what an automated tool might look like.

Tags: Trust, Assessment, LoA

Notes

Self-assessment tool use cases:

  • LoA assessment for IDPs
  • Sirtfi compliance for IDPs and SPs
  • DP CoCo for EU/EEA
  • SP Assurance level ("inverse" of IDP LoA assessment)


Tool Requirements:

  • Responsibility for the tool should be at a federation level. This does not preclude running the tool centrally. This will also aid scalability
  • Tool should send assessment requests to organisations based on contact information in metadata
  • The tool should support multiple question types, yes/no and multiple choice
  • Machine readable responses (yes/no and multiple choice) should be supported by secondary evidence based free text
  • The tool should facilitate peer review; peer assignment should not be determined by the assessee
  • Results of assessments should be made available; individual assessee results would be private to the assessee but an aggregated view should be freely available
  • Fed Ops should have access to the results of the assessments
  • Access control for an assessment should facilitate private and public sharing
  • The tool should support re-assessment and have configurable behaviour in the event that the re-assessment is not done or if it fails


LoA self-assessment tools requirements

Use cases:

For the 'low-risk' use cases, self-assessment is enough, and a tool might be filled in by an IDP operator.

For SirTFi: in v1 it is just asserting compliance - the tool might automatically update the metadata UN the federation - centrally or per federation? Since it engages federation operations, responsibility and ownership suggests a per-federation approach. That will also help in scaling. Use delegation for scaling.

A central tool would bring economies of scale. Running that as a service can still delegate responsibility.

The tool will guide them through an assessment. IDP admin can login to the tool and then fill in the assessment, and then automatically compare. The contact element form the IDP meta-data can be used to generate a login link to that person - so you get the right person responsible for the IDPs/SPs. Using the SAML2 MD as the trusted place for the people who can login to the tool.

The login info can be a shared generic address, but that is still fine - the login will be based on SAML and so you can still see who can actually did log in.

Tool can also add peer review capability support.

It makes available a set of assertions available, and the peer review make them more evaluable. The peer review in the IGTF with known peers adds value to the raw data of the self-assessment. The peers are not entirely random, and an RP review is considered more 'valuable'. In the IGTF, it is expected that participants contribute a bit in kind, for reviews and for attendance.

But every review is value, as long as you can identify clique formation and 'eliminate' their results.

In SAML MD, you can identify SP and IDP reviews automatically.

Trust typically scaled to ~150 humans (Dunbar), and you need a distribution in there. So for a 4000 IDP system you might want subgroups ;-) Looking for clique formation is well known from OpSec trust groups, but also the old Thawte WoT notaries and for the PGP strong set.

For the tool: reporting interface, you can identify the intermediate parties, and these should be visible.

For the tool, visualise compare to avg. baseline maturity - compare to SURFnet maturity scan, and the web diagram (see Mikael's presentation). The publication might have to be delayed in order not to encourage false reporting. Compare to the average is fine, as long as that result in (for a while at least) private to the compared party. For 1-on-1 comparison, you need approval of both parties.

For the 'quality' of the assessment, use a scale - not present, present, documented, document-reviewed, compliance checked regularly (0..5)

Re-assessment should not be possible to just bypass the process.

Self-assessment on entry is fine, but you need persistence of old data.

If the self-assessment changes, who should react? At least the federation should not knowingly continue to rely on false data, so the federation may intervene if the maturity degrades/changes over time.

The proper point is probably the federation.

In the health sector in the US, evolution is modelled after reaction on incidents and then re-assessing.

It may be cultural - required to report vs. assigning blame instead of using it as opportunity for improvement. Or the risk of non-reporting of compliance is too great - e.g. risk of loosing entire ability to operate as a medical facility (for UChicago)

What is the gain for the IDP for using the self-assessment? Adding trust marks by the federation to the SAML MD, and SPs can start filtering on that. The marks get assigned when you meet minimum requirements on the specific trust area - and

People are usually honest, as long as there is transparency and there might be questions - the IGTF found that people are usually self-critical (both in IE and IT and NL). But in those cases there was no negative impact.

What would happen if you were disqualified if it's not all 5's? Would then everyone tick 5?

Maybe: if you claim its document, require a pointer to the document. You need a free text field as to how you came to that statement. Not the entire PDF, but just links, some of which may be to private pages.

InCommon participant operating practices has a few issues. One was the free format, so a structured format will help here. The SCI document has a structures set of questions. You need automation here.

Should the tool publish the answers? This has to be access controlled. The results may be shared, targeted at specific consumers. Share with federation operator, share with the e-Infrastructures so that they will then allow your IDP in (maybe they only do that if you agree to share the results).

Identifying the people with whom to share? Take from the SAML MD, but using the link-send-ID mechanism also used for IDPs now for SPs?

Also share with the federation operator.

Visualising? The federation may aggregate the results for each self-assessment and assign an overall label to it (bronze, silver, gold, or so). But not visualise the details.

Spider diagram categories - configuration issue for the tool.

Tool can serve multiple purposes, for the identity VoTs how many trust marks go in? How many aspects we need to cover is still open (now 6). Too many does not work either. Elements could come from SCI or the IGTF APs.

Tool and answers should be versioned.

Result of this should be a requirements document. Use cases of the tool:

  • LoA
  • SirTFI,
  • DPCoCo for EU/EEA
  • SP assurance     (interplay/duality - focus on privacy, meaningful error msg, incident     response notification by SPs to IDPs when there's something fishy with a     user).


Never ask for the level, ask for the community requirements.

Is there an existing tool? Qualtrics maybe?

For the Kantara requirements it's currently a PDF, but now changing to excel, later move this to an on-line tool.

Worst case the tool will just be a survey …

A page for this topic was created on the wiki of project AARC/Policy Harmonisation:
https://wiki.geant.org/display/AARC/AARC+Policy+Harmonisation

Session 10 <Protect a PDP with OAuth2 a good idea?> (11:30/Room K7)

Convener: Peter Gietz

Abstract: Within the DARIAH project the Non-Web SSO use case of accessing data on the distributed storage needs to be solved. The proposed flow starts with the user authenticating via her browser to a web application(in this case the user interface of the DARIAH repository), using the standard SAML Web-SSO flow.The DARIAH repository stores data and reads data through Rest API and the problem was to enforce the access rools, like member of a particular group is allowed to read a particular file, on this level. As solution the existing PDP shall be integrated with an OAuth2 AS. The architecture was discussed positively and it was identified that in the last part of the flow (the REST API Implementation asks the AS to verify the token) has been standardized very recently in oAuth2, see RFC 7662.

Tags: Non-Web SSH, Oauth2, SAML

Slides:

Notes:

A Policy Decision Point (PDP) is a good thing if you have complex rules for access decisions, so that the application (the Policy Enforcement Point, PEP) does not need to evaluate such rules.

Within the DARIAH project we want to have access to the storage where there is no user on the browser (Non-Web-SSO). The flow starts with the user authenticating via his browser to a web application (in this case the user interface to the DARIAH repository, using the standard SAML Web-SSO flow.

The user interacts with the DARIAH repository and the DARIAH repository stores data and reads data through rest API and the problem was to enforce the access rolls, like member of group x is allowed to read file z.

The PDP integrated with an OAuth2 AS is where the access decision is made.

We experimented with integrating OAuth2 into a SAML based federation, and we had an RBAC standard based decision point that can take care of access control, access control on single files. The idea was to get this info about the access control to the DARIAH Storage API via OAuth2 that only gives out tokens after checking with the PDP system whether the users are allowed to or not. The question for this Session is: are we sort of misusing OAuth2 where generally the user will be asked to authorize a token and now we use the PDP instead. What do you think about this, or are we misusing the OAuth2.

The Rest APIs don’t support SAML, and the SAML token security profile is not used, except in a few communities. The rest of the world is looking into OAuth2 tokens and we decided to go with the OAuth2, using SAML instead of Open ID connect.

Charis: Do you label your information, if you give a token back that means that someone has the access to the storage then you risk to allow anyone to rewrite every file. The basic idea is that you must give a different token with a different scope every time and the storage must be able to interpret that unless you send the token to the PDP in an XACML style request (Subject, object, action) get the result to permit or deny access.

Convener: The storage API knows from the repository software that the user x (who) wants to read (how) the file y (what). RBAC system will be deciding and normally the RBAC will say yes or no and the storage API will do it with a privileged account. Now the API will only get an OAuth2 token(in the HTTP header) and will access the Storage-infrastructure (irods federation) with this token in the name of the user after checking the validity at the OAuth2 AS, as a one time decision and every access you will get a new authorisation token.

Radovan: The interaction in step 7 (Token validation) is not standardized?

A: There is no standardization in the 7. The current implementation of the Storage API will be enhanced with the OAuth2 (Token in HTTP header), thus the actual API will not be changed.

Convener: 1 and 2 is SAML authentication, 3 is the basic question is sent if the user is allowed to access file x or y and this is the SAML protocol question and the response is an OAuth2 token presented in 4, if the user has the access and the 6 is an HTTP with the token and the 7 you mentioned is the API is to validate the token if the token is valid and the token validation is a part of the OAuth2 protocol.

Charis: In 3, you are using the userID as a scope?

The user has a particular role (separation of duties), at one point of time the user selects the role in which he wants to act.

So the user ID is a role ID?

A session connected to a specific role.

Albrecht: Were the storage API modified?

It’s a design phase only so input is needed and the storage API exists which is a simple HTTP rest API and by now every access decision has to be done on the repository level and what we want to do is to have the access decision at the DARIAH Storage API.

Albrecht: Is it the interactive session with the user?

The interactivity with the user is only at the beginning of the Session (Web-SSO) but then the repository will have the notion of the user and with it will get the access possibilities of the user.

The step 7 is actually not standardized in the end. But the UMA standard has this kind of strategy. OAuth2 is not a protocol is a protocol framework.

Albrecht: The OAuth2 might not be good in the long-term track though?

The entity points of the API will stay the same and the functionality will too but that we only demand in the http header the implementation of OAuth2. It could potentially also be working with the SAML security token.

The only thing is that all of the components need to be in a trust framework so that DARIAH has to trust the federation the SAML federation and also has to trust the combined PDP/OAuth2 server.

Albrecht: How distributed is your architecture?

The idea is to have as many of these building blocks that are distributed, we will have lots of instances of the storage API (at every computer centre involved), Also the repository is designed to be distributed, but the meta data management has to be on one place and highly available but there has to be one sort of master index somewhere. The PDP can also be distributed, since the policy information point will be an LDAP server that contains the data so there we will be many instances of that.

Charis: So you are building a federated object storage?

The problem will be the storage of tokens as long as they are valid. Yes of course the tokens will be the stored in the RBAC+OAuth2 and they will be deleted if they are not validated. The time of how long the tokens are valid is a matter of minutes.

Albrecht: I believe the minutes are not a long time to live - is this an issue?

It is not about the clock of the computers of the servers API but the OAuth2 have to have the same time. LDAP is used for storing the information about the sessions, about the roles and the OAuth2 tokens. The time issue is about storing the tokens and if the tokens are held up there might be some performance issues, if there are such issues we will just store them in another database.

Step 7 is just the validation of the OAuth2 token if the token is still valid and if the token is validated by the authority in the first place.

Session 9 <IDPs of last resort: user-centric identity> (11:30/Room K6)

Convener: Laura Paglione

Abstract: IDPs of last resort: user-centric identity - unique challenges

Tags: Guest IDP, User-centric Identity

Notes

What are IDP's of last resort, what different models are available? What can Orcid deliver and what not, and is ORCID an IDP?

Session Summary:

  1. Described several IDPs of "last resort" that are available - several participants are running, designing, building and/or using systems like these
  1. Talked about the traits for IDPs of "last resort", particularly that context matters
  1. Discussed, "Is ORCID an IDP?"

Main issues discussed

Survey of IDPs of last resort

What is an IDPs of last resort? – Concept of long lived identity, protected network,

There was a situation where an IDP started offering free identities for people who needed them, though after some time some IDPs disappeared.

Sample IDPs of last resort:

  • umbrella project in EU
  • Social accounts (Yahoo, Google, .net)
  • Leif's project (UnitedID)
  • Pete's project
  • Jim/Scott's project


ORCID is a user centric system which allows the control of information shared with organisations and people while controlling trusted relationships with organisations.

LP: interested in discussion about the user / federations where an institution manages, is related to that person, how does it work. Does it replace the version of it?

Aud: Out guest identity provider is social, we are using social media as last resort.

I.e. Yahoo, in middle income countries / Mali / facilitate deployments with IDPs.

People don't have internet access in Africa, on research side – these are mainly doctors, medical personnel, scientific research staff, laboratory, many of these people are affiliated with local institutions (universities), but even they don’t have that infrastructure ready and we help them do that / also do this research in other parts of Africa.

Q: is this sufficient for your needs?

A: it’s not ideal.

We should obsess less about the fact that we keep multiple IDPs around, the notion that Google/FB are better or worse, for some of users it’s a safety thing, allowing people the choice on what identity they want to go with – I’ve been arguing that instead of trying to pick one you should make a history of your IDPs. We have many guest IDPs of last resort, that doesn't really work in global co-operation. We have no clue about local guest IDPs of last resort and will force user of using only one.

Also: we are focused on the 80/90 percent, for some this question is life threatening / this is what you should expect from unaffiliated, we should produce a list of IDPs of last resort

LP: FB/google identity – is there expectation for switching it?

- It is a common misunderstanding that people expect unification. People are usually not comfortable with using multiple identifiers.

Participant: we should allow the user to make a decision.

If that means we have to provide a little bit of structure around the IDPs, fine.

  • Google is not going to give you ECP
  • You could have some kind of list that the identity provider
  • This IDP is generally available for people who don't have one yet


Other topics?

I wonder if, over time, what’s happening when people have only one loyalty programme.

  • This has been discussed for a long time, it never happens. I don't know that people put up with it or whether it’s a choice, I think people are thinking about it more, I also believe that that prediction is helping about.
  • Choose not base decisions on the notion that people will surround behind one single loyalty.
  • Federation is almost becoming an anti-pattern for people, they want to multiply their identities - no federation is going to give you anything.


Q: wouldn't your biggest worry be the liability of a password store? How am I protecting my password store?

Q: will ORCID be an IDP?

Tricky question, we are just identifier – why is this question coming up?

  • Your target audience is exactly the kind of people we are developing that for
  • How does it affect the eco-system, when everybody gets linked to everything always?
  • You’re basically creating, i.e., foundations where it’s hard to break a relationship - what information can get lost today? What interest does the community have?
  • Even when you say ORCID is not an IDP, for me it is
  • ORCID provides a persistent identifier for many years; now integrated into many websites
  • The term IDP has so much attached, when we say were not – in a way were closer to Google ten years ago, we have password issue for now, it is not well suited for any kind of transaction – information what users controlling is publically accessible, you can log in with ORCID, it can be set up all you get from that is an identifier.


Participant: semantics?

  • The assets behave like an IDP, she's telling you what she is capable of taking liability for you say you get a name from ORCID, so what, without authentication.
  • ORCID should say: here’s what you should the ORCID name for, here’s what you shouldn’t use it for.

How do you stop people from acting irresponsible? -- You can't!

  • As service provider we're thinking about using ORCID, in a few years
  • I’d like to have a statement from ORCID that says what ORCID can provide.


I.e., always provide an option, don't force people into a single choice.

Conclusion

Q: What can ORCID deliver? What not?

Q: Is ORCID an IDP?

When people say IDP there's a lot of implied meaning, and ORCID may or may not provide all of the components that people mean. Users can log in to ORCID and ORCID will provide the service with an ORCID identifier, but it isn't suitable for access to resources that require high level security.

Added later after session: InCommon IDPoLR Working Group Final Report (targets IDPofLR for research and scholarship, not general users) is at https://spaces.internet2.edu/display/IDPoLR/IDPoLR+Working+Group+Final+Report

Session 8 <Quality of Authentication and identification> (11:30/Room K3)

Convener: Peter Pichler

Abstract: IDPs of last resort: user-centric identity - unique challenges.
What are IDP's of last resort, what different models are available? What can ORCID deliver and what not, and is ORCID an IDP?

Bullet points:

  • introducing to the Austrian authentication and security requirements
  • low and higher LoA, 3 security classes are 10 years old already, modernization going on
  • single factor and two factor auth. for higher level
  • in addition network level security or working place security (some resources can be accessed only from intranet)
  • eIDAS has 3 level LoA for citizen authentication (the presenter’s use case concerns Austrian civil servants)
  • eIDAS 3 level LoA based on ISO standard
  • low passwords
  • substantial two factor auth soft
  • highest two factor hard
  • https://www.igtf.net/ap/loa/
  • "The IGTF Authentication Profiles de-facto describe a technology-agnostic assurance level that represent the IGTF consensus on achievable trustworthy authentication seen from both the relying party point of view as well as being a feasible level for identity service providers to achieve for a variety of scenarios."
  • of those present most have not implemented LoA
  • IGTF has defined levels of assurance
  • Kantara IAF (Identity Assurance Framework)


Main issues discussed

Introduction to discussion:

Austrian eGov federation - a project for many services, authorization, security requirements with high assurance

Security classes from 1 to 3 - this system is 10 years old - we try to further develop it

  1. the type of network
  1. the quality of authentication - how the used is authenticated (low- just a password, higher with another authentication, for example a call or extra code)
  1. resources combined


This qualification is called in Austria "security classes".

To be discussed: classes and problems (government to government services)

For governmental use cases and also business cases.

Comment from the audience:

The eIDAS 2015/1502 Implementing regulation - seasonal authentication http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2015.235.01.0007.01.ENG

Implementation acts

  • 1st layer password
  • 2nd tokens, delivered to the user
  • 3rd (highest) - extra, tokens or other authentication delivered to the user face to face


Question to the group: Are there examples on any form of a classification? Or plans to do something like this?

Audience: IGTF has defined levels of insurance

(Example: for scientific calculations for research work)

Summer federation based on protocols "authentication context"

- Possibilities to describe (in the case when the users forgets the password) - in a larger federation it is difficult, the higher (1,2,3) classification is a better solution.

Service providers have different security standards/policies - the classificated level of insurance should simplify this.

Kantara IAF SAC (Identity Assurance Framework) is also a75 framework, 4 layers called assurance levels (organization maturity)

(this was discussed in another session - K2 09:45 Wednesday - Tom Barton "Trust and assurance" & Identity Assurance Framework - building critical trust)

Conclusion

Classifying (levels) could/should simplify the handling of different authentication qualities in an identity federation.

(Peter Pichler is working on improving the Austrian framework.)

Session 7 <Fields of anonymity: understanding the dimensions and futures of identifiability> (11:30/Room K2)

Convener: Paula Bialski

Abstract: Fields of anonymity from a sociological perspective: How are the regimes of anonymity changed and maintained? How do they affect social life?
Topics discussed include: perceived forms of anonymity vs. real form of anonymity, pseudonyms, linkability, risk assessment and more generally, data collection policies by companies and the question of how to raise awareness regarding privacy.

Tags: Anonymity, Pseudonymity, Unlinkability

Notes

This topic is part of a research concerning anonymity.

Background of convener

  • Worked on trust, in-house sociologist. PhD: studied couch surfers. How to promote trust to start sharing their trusts. ("What is a couch surfer?” from the pre-airbnb era; two people don't know each other -> need to interact online)

Project just began in August; it is a trans-disciplinary endeavour between sociologists, anthropologists, psychologists etc.

Maintaining contemporary high offline world

Regimes of anonymity: How are they changed and maintained? How do they affect social life?

Forms of anonymity:

Useful tool, important for freedom and trust

Anyone from starting an app, to airbnb, to Wikipedia, etc.

Q: What are they doing to protect their users? How do they deal with their data and addressing humans?

--> 20 interviews, half hour to 2 hours.

Mozilla: contextual identity: promoted pseudonymity in browsing: new system: open tab browsers. You can browse with different names and contexts -> don't have to log in separately, they are going to launch it soon.

Q: What tools are they inventing and envisioning -for- the users?

Practise forms of anonymity

Difference between (1) perceived forms of anonymity <-> (2) real form of anonymity

  • Facelessness/namelessness doesn't mean we're not fully anonymous online.

Question to audience: incentive for research.

What tools are being developed to help maintaining the anonymity of the user?

1. Perceived forms of anonymity

2. Real form of anonymity

Convener: you can think of forms of encrypting anonymity -- architectural level: where they 'log in': hardware or more abstract?

aud3: risk: between (1) and (2): no one goes online to interact with their IDP

Pfitzmann&Hansen wrote a relevant paper on anonymity, pseudonymity and linkability (https://dud.inf.tu-dresden.de/literatur/Anon_Terminology_v0.28.pdf)

Online world: anonymity becomes a hard task

Austrian national ID system: citizens are provided with pseudonymous ID

Your poster code may be enough to link driver's licence ID to health care ID (-> linkability)

aud4: opinion on online vs. offline verification processes?

You can upload documents, videos etc. -> doubtful quality

Convener: can't really comment on this at the moment.

aud5: general remark: real anonymity: you can't really achieve it. Triangulation.

Where does my personality start? Name, address, date of birth...

Cookies: part of ID. Always possible to link it to my person, always part of it. Behaviour tracked online.

Organisers of this conference developed a federated model with limited linkability and limited observability. Not a single actor in the system would be able to get back to the ID if the user uses a pseudonym. If one single point of info is given, the relying party does not know everything. This system needs at least two actors to get link. However, there are several levels (IP address, browser fingerprinting) where unlinkability is broken.

aud6: background: psychologist. Data that is augmented onto your personality. Psychological research: people can assess personal traits reliably by looking at a FB profile for 2 minutes. // guesses on personality traits. Humans use that data // huge privacy issues

Convener: Is this question something that is discussed -only- in the 'privacy by design' discourse or also in -your- field? Where does this discussion take place? If it doesn't take place at all, is it packed up without wanting anyone to touch it or talk about it?

Aud7: Background: trusting 3rd party - policy of not storing anything.

Another issue is acceptance: 'the internet remembers everything'. Company: if you move from one office to another, they should remove everything but in fact, organisations tend to keep everything. As to my experience, a discussion is not happening.

Aud8: What do we keep anonymity for? What are the goals? Risk assessment/management: What's the current threat and what could go wrong? What measures are the most important to take?

Conv: quite general, how does it work?

Bizarre: people want to give away information in community (offline) <-> but in another community, they don't want to give away ID data (online) - WHY?

aud10: representing ideas of needs of companies and individuals - being in a community: relevant to job - discussing, being in forums etc. -> attributed to CV. what you have posted etc. makes your CV more or less reliable. Companies need proof, they need that to assess someone's qualifications. CV data is not reliable enough at the moment. They’re moving towards social linked data.

Jamie: Not an expert in the sociological field but it seems that in the offline world, contextual relationships matter. From an early age on, you behave differently towards parents, teachers etc. -> different people -> different expectations. In later life, you apply that to your profession, and private life, respectively, by keeping personal data separated in different contexts. Where does your personality start? Someone got a neighbour since 7 years, doesn't know his name but trusts him because he brings him his parcels. He knows the name of his other neighbour, however, he doesn't trust him, as he throws nails into his garden ;)

Keeping online contexts separate from offline contexts: sometimes necessary, sometimes it's difficult to maintain separation, e.g. work phone / personal phone.

Mozilla wiki site: Contextual Identity Project/Containers:
https://wiki.mozilla.org/Security/Contextual_Identity_Project/Containers

Convener: How useful are these (which) tools - both for users, developers and site administrators?

What are the issues which prevent the mass adoption of these tools?

aud12: Most people don't care although they got responsibility.

aud13: Awareness is all around. ID security research: Developers only start using tools as soon as it gets into their framework.

User thinks: somebody has to take care of this. How do we engage people to use it (?)

aud14: Create a legacy environment (by and large it's not amendable) to practice anonymity. Users can project themselves by means of organisations.

aud15: incentives! Many people don't care. Legislation is able to create incentives as well to create more privacy. /// There must be something economic about it /// paying fines i.e. (something bad happening). Identity is often not the goal but the key to access something. ID helps me to establish a relationship with government agencies or organisations. They have the ability to change the conversations that help foster relationships.

aud16: Encrypting products is hard: The vendors of products usually don't have a user interface, hence implementation is sometimes real bad. Crypto-implementations should be created together with the vendor.

Conclusion

website: reconfiguring anonymity
http://reconfiguring-anonymity.net/

Get in touch if you're interested!

Session 6 <Dynamic sca/aS/e metadata exchange> (11:30/Room K1)

Conveners: Michael Grabatin, Daniela Pöhn

Abstract: A different approach on the communication in between an IDP and a SP without the usage of a proxy as the third party but instead using GÉANT TrustBroker. This approach has many advantages compared to proxying and the first and most important one is the simplicity in the architecture, as it requires only a one-time authentication and none more afterwards.

Tags: Trust, SAML metadata

Goal: dynamic metadata exchange workflow, orchestrated by a trusted third party.

Background: https://wiki.geant.org/pages/viewpage.action?pageId=45844180 (for more information)

Identity provider (IDP) and service provider (SP) do not technically know each other beforehand, exchanging the data on demand via a trusted third party (GÉANT TrustBroker).

The core workflow is explained:

  • The user selects his IDP at the trusted third party (TTP), is used to authenticate
  • The authentication request of the SP is cached at the TTP and a new authentication request is generated to the IDP
  • After successful authentication of the user, the metadata is exchanged and then integrated
  • If the SP needs other attributes, then the IDP has currently, conversion rules are needed
  • Attributes are user information with some semantics and syntax
  • IDP and SP might have different format -> Attribute conversion rule can be provided by the TrustBroker.

Business goals and purpose of the metadata exchange between IDP and SP via a TTP:

  • Scalable approach in order to have less problems with parsing the aggregate
  • Provider does not have to join another federation or set up their own federation.
  • Simple workflow integration. Administrators can be notified by e-mail and asked if they allow the connection

Q: Why is it better than proxying?

A: Because the TrustBroker is only involved in the first metadata exchange, for all following authentications it is no longer involved.

Q: Do you have an IDP black list?

A: Yes, there are black-lists and white-lists to limit which providers can exchange metadata

The provider administrators want as much control as possible about who they are trusting and which attributes they are releasing.

The discovery part is not in the main focus of the TrustBroker, many projects trying to solve discovery problems. It might be combined with something like AccountChooser.

The metadata exchange can be rolled back.

Q: Why is it dynamic?

A: It is exchanged on demand, when the user first accesses a SP

Comment: A real advantage would be a complete workflow engine, because access decision need human decisions, possibly from several persons. Example: the user would hit the SP, the SP would request the IDP to be allowed (the user would have to wait anyway). The IDP might decide later if the SP should be connected. The user would be notified that the connection is enabled.

Video showing the user experience of connecting a SP to a IDP: https://wiki.geant.org/download/attachments/45844180/2nd_shot-3.mp4?version=1&modificationDate=1435041552887&api=v2

Some projects are outside eduGAIN, they have a problem exchanging the metadata.

The metadata is regular SAML metadata. For the communication with the TrustBroker additional fields have to be added in the extension field.

Laas:

We take only entities from eduGAIN that have validated their attribute release policy. This is done by hand-picking, which causes the scalability problem. CoCo and R&S entity category help.

The metadata distribution has problems on different layers:

  • how do you transport securely
  • how do the processes work

The processes are currently often not in place or manual.

-> The TrustBroker offers a simple workflow, that sends an email if asking the provider administrators if they allow the connection

Rainer:

If you have a workflow you need some kind of a scheme for it, you have to define your custom workflow.

Laas:

I would want to know that the IDP is not an anonymous group of hackers. -> Signature verification, registration

Conclusion

Q: How to actually improve on the trust of the metadata?

A: If you have this small virtual organisation (VO) enter the federation. Getting a letter from the dean could be added to the connection application, to prove the connection is needed and authorized.

Q: How do you establish trust?

A: The dynamic registration the TrustBroker implements (similar to OpenID Connect) seems to be not trustable?

The workflow is the key component, not the metadata exchange itself. Move focus from technical trust to workflow support.

Session 5 <SAML Test Tools> (10:45/Room K7)

Conveners: Roland Hedberg, Rainer Hörbe

Abstract: Project that focuses on creating testing tools for different forms of access configurations (which are including an option of fingerprint recognition) that can be used by a whole community of identity experts.

Tags: SAML, Test tools

The front end wasn’t built yet but the thinking is already up. If you have a set of IDPs and you want to continuous integration and if they switch to another software version then the test is being run automatically, as soon as the IDP is changed, it has to be ran again.

Automation is a problem if there is an authentication where a person needs to sign in. There are several options how it can be mechanised.

Q: How do the people do testing?

A: One forma are unit tests, which you configure manually. The unit tests are fairly automated.

The tricky thing is how to get the configuration data in place, so if many SPs in a federation test with (slightly) different configurations, it would be a copy paste hell that would be hard manage.

Other use cases would be different, the first tests would be for IDPs and check the functionality, like if it’s able to consume the metadata and to verify signatures. For SPs it would be more automated. It could be used as a tool for a service that is asking to join the federation to test the SP.

Rainer: I am interested in the different use cases that people have for using SAML tests.

Nick's FO use case:

Local IDP machine, an IDP tester, it has the tests I want to run...

The test takes to the IDP, there is a legend which shows what kind of errors or reports you might get.

If saml2int is executed, then another set of tests is established, if there was some kind of an error, then the code can be checked by clicking on the question mark and there can be checked and seen what went wrong or what was the error in the code.

IDP form pops out on the browser in any case as the automation hasn’t been made.

A proxy is also a possibility. Peter couldn’t enter stuff with only HTML. If you want to mechanise it, this is the main information, it has to match the URL, there is a login page and a form that looks for the sets of input boxes, and that’s it, you press the button, mechanise and you’re done.

Pietu: The providers are mostly commercial and they are interested in testing the functionality.

Informal lightweight community should be created where the idea can be worked on.

Rainer:

There is a test repository where you collect the configurations. Question to the group: Would it be in a Jenkins server or a Cloud based application, or would you download it into your infrastructure?

Wolfgang:

Current practise is when IDP wants to join the AI, he has to join the federation, the SP logs have to be checked for errors and after red and green light come up it should be moved to the production environment.

Idea is to deploy the IDP test with two or three common configurations with different entity IDs, so everything would be in the test federation metadata so that we don’t have to check everything but we can see what happened where.

Roland:

The tests can be run by the federation all the time. If the user is having a problem and you want to see what happened, these two can be quite useful, you can point the user to these tests and probably only one button should be clicked and the result of the test would be sent to the tech support automatically. That could be one useful thing to do.

Rainer:

How can tests be utilised and what are the test cases? Are we testing IDP and SP?

The test federation should be assembled and to practise the tests there.

The idea is to have a list of specs and each chapter has a number of requirements, these are the existing labs, and each requirement is supported by a number of test operations. The test is gotten from a little bit of configuration.

Test case: fingerprint IDP/SP version.

A database with tests should be good to create. The fingerprinting should report the version number of the software helping to flag insecure deployments. Operators can to notified to upgrade the version of Shibboleth.

You really want to test the security, e.g. you could test if an SP would reject a broken signature. There was a product that went into the market already and did not check the signature at all.

Otherwise check general functionality, see if it is consuming updated metadata.

SP less automated: preconfigured test handed over to the SP operator, who has to complete the config and run the test, then feedback the test results to the FO.

Session 4 <ORCID as Attribute store: What would it look like?> (10:45/Room K6)

Convener: Laura Paglione

Abstract: ORCID as attribute store: What would it look like? (user centric release). How does the ORCID identifier look like and what are the advantages of getting an ORCID identifier? What models could be thought of in obtaining the ORCID identifier?

Tags: Identifiers

SESSION SUMMARY

  • One of the key things that participants were interested in obtaining via ORCID as an attribute provider is the ORCID identifier itself.
  • Models were discussed for obtaining the ORCID identifier - the key use case was finding an ORCID identifier after a user has logged into an IDP

Primary topic is the difficulty of getting attributes from IDPs.

Discussion around the usefulness of getting an ORCID identifier -- it is useful, but how do you do that?

Everybody has been trying to find a solution to get a persistent identifier, but you don’t get a universal unifier from IDPs. Identifiers can be reassigned and/or require a particular context, that’s why they want an ORCID identifier for an identifier.

ORCID might play a vital role as attribute store.

Harder problem: using the university credentials:

  • on screen where someone signs in: screen with ORCID OR institution OR social login
  • any of these clicks can be tied to the individual
  • ORCID has record of the links the individual used
  • case: we could confirm: this       person has logged in before in one of the 3, which one?

Q: How can I make validation that this is the same user?

ID – alternative person IDs can be identified; we have to understand what the privacy implications are at ePPN.

Q: What if service already has identifier?

A: Own institution has identifier for Individual.

Q: No way to get an identifier for a person?

A: There are sorts of a prerequisite, using the identifier, if I create an ORCID 5 years ago and leave university and try to get access to university again?

Service ---- ORCID ---- IDP

Somehow unique identifier needs to be established. ePPN can be seen, but that cannot be tracked to person / you need some other attribute.

Many IDPs don’t release any info about users. And universities are scared to release the name if they release ORCID.

Q: How can ORCID attribute store see an identifier, which gives us some assurance?

A: Service asks ORCID for identification, ORCID should ask user and confirm.

Q: How do we know that it’s the right user? Also when he logs in back again one week later?

A: There is no unique identifier with IDP – we need another identifier/create one.

Q: how is this different from now? Is that even possible?

A: We need a way of knowing that we talk about the same user, everything happening in that session is the same person.

Q: if user creates more than one ORCID identifier, it his problem?

A: we expect users to use the very same ORCID identifier.

Session 3 <Attribute authorities discovery (protocol)> (10:45/Room K3)

Convener: Davide Vaghetti

Abstract: 3 Use Cases for Attribute Authority. Possible solutions for Discovery.

Tags: Attributes, Discovery

Attribute Authority (AA) Discovery

In every case you need an attribute authority but only one (the third one) needs discovery:

1. Authentication Authority is Attribute authority: AA Discovery is sufficient.

2. VO AA that knows about membership info that the Campus IDP (AA) does not, but the SP will know which VO AA to contact.

3. Usage of external AA like eGov ID, things like Switch eduID or Social IDs, there only the User will be able to tell which AA to use. This use case is in need of AA discovery.

Possible solution for AA Discovery

1) Attribute Authority WAYF (after authentication)

Pros

  • It does apply to every SP in need of AAD
  • It is not bounded to a specific attribute or set of attributes

Cons

  • It does complicate the resource access process
  • It puts another burden on the user that has already passed WAYF to choose IDP.

2) Attribute Authority Central Discovery and Collecting or “(A)AC/DC”

Pros

  • It is transparent for the user until we do not have collisions in attribute collecting (i.e. multiple values for single value attributes)
  • It is consistent with EduKEEP - user-centric identity management model

Cons

  • Difficult to implement for every and each attributes, but not that difficult to implement for just some attributes (i.e. schacHomeOrganization)

Also take a look at: EduKEEP: towards a user-centric identity federation
http://meetings.internet2.edu/2015-technology-exchange/detail/10003996/

Off- topic discussion, presentation of a Dutch UETP Uniform Economic Transaction Protocol

Discussion about Identity Layers in Bank domain:

  • Who entities (who legally represent)
  • What entity
  • How entities (rule sets)
  • Transaction entibining who what and how with timestamp and location. - transaction entities where how, when, where can be combined

The idea of the entity becomes data-centred as open source - it is important to cooperate. Real-time relevant authority routing. ID is a set of attributes like MAC address, IPv6 Address, connected by a handle based on RFC 4122.

Conclusion

Attribute Authority Discovery will be necessary for R&E when eGovID-like technologies will be delivered.

An Attribute Authority Central Discovery and Collecting mechanism or (A)AC/DC seems to be the simplest solution.

Session 2 <Baseline Trust & Assurance + Identity Assurance Framework - Building Critical Trust> (10:45/Room K2)

Conveners: Tom Barton, Joni Brennan

Abstract: Kantara - Identity assurance trust framework. How to comply with government’s ideas and how to translate their requirements and the capabilities of organisations? What to expect from ID & service providers? How can we get communities to work together?

Tags: Trust Frameworks, Assurance, LoA

Joni Brennan:

Kantara is a non-profit organisation creating strategic vision for digital identity transformation.

Moving into a strategy for the growth and development of trust, which is validated through certified 3rd party auditing programmes.

Identity assurance trust framework

  1. Trying to build tools to make it more adoptable
  2. Trying to remove complexity

Relying parties provided requirements, which were fed into Kantara's framework, very open and transparent (all available online).

There is the need to translate between government requirements and the capabilities of organisations.

  • Program is currently running in US.
  • The US government has come up with the idea of a credential service provider. Kantara has taken this and broken it up into modules.
  • Key value of Kantara is to link up individual players in the chain of credential service providers, e.g. identity proofing and token management.

Working closely with eIDAS in Europe, program in UK and Canada.

--> what's the baseline?

"Special snowflake" syndrome: unique requirements. 90% are very similar; Kantara is focussing on the deltas and building bridges.

Reports of LoA assessment are stored in both machine and human readable format and can be leveraged by further systems.

Interesting: framework also works with non-traditional partners

Challenges: systems in US are struggling, as they do not leverage the social approach.

Partnerships: healthcare system: Health risk different from other risks

Components

Concept: vectors of trust: Token management, identity proofing, attribute binding, incident response and reporting… what else? Measurable components

What are the specific areas?

Levels of assurance: Low level 1 --> up to 2, 3... (Linear scale) some scales less linear

Q: How to reach the right measurement?

Tom Barton:

BASELINE TRUST

See slides: Download: S2_Baseline_Trust.pdf

There has been a strong reaction against the idea of a linear relationship between risk and trust.

Aligning with governmental ideas is difficult; large amount of effort required to get Kantara certified.

There’s been progressions:

  1. Creating profiles
  2. Working with federal government

There’s meant to be a value. The original approach failed since the cost was too high. Identity providers in InCommon turned out to be (reaction): Incredibly expensive -> failed.

Assurance profiles (e.g. Kantara) were too heavy for InCommon purposes. In 2001: InCommon's Participant Operating Practices were too light, non-verifiable.

What is it really that should be expected of id providers and service providers?

Assurance in the community: They came up with an easily understandable solution: there should be layers of automation and profiles, considering the case of federation.

Slide: potential participant baseline expectations

What to expect of IDP? Or as IDP: what to expect of SP?

Listener

  1. Everyone's a stakeholder
  2. If these exp. aren't observed - what to do about that?
  3. Problem: this stuff has already been done in production by businesses and Gov. baseline for expectations: what's going on in Europe? 6 or 7 businesses: bad policy. They HAVE expectations for both IDP and SPs.
    Gov: regulated industries that have to interact with gov's.
    Conveners: we're talking about diff communities. It’s more about communities working together (in our case they don't do: in the private sector: want to offer their services - gov intervenes). // it's a process. It’s about humans. All trust springs from people. Problem in our context: small scope; trust within. Thousands of organisations globally. There has to be an unburdened conversation.
  4. Peer review: doesn't work if they tell that practise is being followed
  5. Observation: Many federal work the same way. Operation operator role has been pulled back. Gut feeling: you could move in the opposite direction. Problem for trust. You have provided a middle layer. Organizations do not willingly rely on.... make parties make their own decisions. If all organizations share the same system. Can work fairly well.... Objection of audience: "that only works if the transaction is relatively low. Does not work if you have high risk and high value" composite source trust: several sources of authority.
    Same conversation over and over again. There are going to be multiple protocols for a long time. --> what's the right way to go?
    There are multiple solutions - need to put the right one in the right time.
  6. How to establish trust amongst diff stakeholders. New problems crack digitally. Problem we face as consumers with privacy policies: doesn’t tell you things YOU want to know. Would be good: they express what is relevant to you. What are providers willing to sign up to?
    Making privacy policy statement <-> what your statement commits you to do.
    Judgement calls: to more outcome based approach. It’s the stakeholders in the community who decide.
  7. Presents: interviewed research structures that could be relevant for IDP.

Peer review of self-assessment: start a low level and then expand

- There’s no statement about the right for the user. IDP typically consider themselves as owners which makes it hard for others.

Discourse will continue.

Discussion:

David S: supports the InCommon framework

Scott K: fed operator should be represented (there is a FOG mailing list, fed op should ensure voracity of these statements)

Peter: Didn’t do homework, already been done in production in corporations. Should check European BCA, all based on anti-seeing baseline contracts between partners. Governments, regulated industries have to interact with governments’ apps that drive topics such as this. Need to baseline before blue sky thinking… {Joni} we are taking different communities, need to teach and help communities to work together. Governments have expectations but these do not compare with abilities of private sector or research and education. Mismatched expectations. {Tom} blue sky thinking can have useful response. Community has spent time paying dues with no return. All trust springs from people. How do we scale that from individuals to 10s of thousands of organisations globally?

Need to find a way to get there, one of which is a social mechanism. Need to talk about what we expect. Needs to be an unburdened conversation.

David S: observation of challenge between peer to peer and hub and spoke networks. Difference is driving much of the trust. E.g. switch operates as hub and spoke, huge amount of responsibility but based on contractual relationships. Full mesh can work in the same way. Take away complexity from IDP and SP; federation acts as broker providing middle layer of trust.

David G: a set of organisations in a well-regulated space can work together based on guidelines, however in a more distributed environment the cost is comparable to the benefit. {Peter} that only works when risk is low. {David} depends on where you source your trust.

Joni: Are we doomed to have same conversation over and over again? There will be multiple protocols for quite some times, metaphor of different forms of transport for different purposes. Sometimes going in with auditing is fine, sometimes self-assessment is enough.

Robin: stated expectations is a helpful idea. Some of what we are experiencing is teething trouble. Business of establishing trust between organisations with different purposes is quite a new problem to crack. As consumers reading privacy policies of websites, these don’t tell you what you want to know, tell you info from website’s point of view. Wouldn’t it be nice is the SP would express its commitments to you as a user. This is what we see here in Incommon’s framework. This makes it auditable since you can ask for a test or proof, same principle as in privacy policies. There is a maturity step between making privacy policy statement and the actual work behind it.

Even professional auditors will have to have some peer review of their own practices. Moving away from self-assertion to audit where people are required to show how they are fulfilling certain behaviours. Some audit not completed since method of audit not defined.

AARC self-assessment is required for lowest level of LoA, supplemented by peer review.

 

Convener: Gerben Venekamp

Abstract: The system of offline Single Sign-On interfaces where a user just has to login once in order to gain access to the whole network of interfaces. Interfaces with a very high trust level as they are all based locally which use passwords as user authorization.

Tags: Non-Web SSO, SAML ECP, Moonshot

Notes

SSH Key proxying

Cheap to deploy, but not so cheap to the user himself. There are very smart scientists but no smart computer-scientists.

Non-web SSO

  • Trusting some interface that is more local to you. As it is more local in scope you trust it because you have more control.
  • FIDO-based identities. It’s key based encrypted authentication, it's Javascript, it needs a browser.
  • If you stick with SAML ECP, you will have a password.
  • For every non-password authentication you need a client.


Why do you see an ECP as the good trader?

Matthew: what I wouldn't like is the required usage of a password. I give them the certificate and they can enter, using a smart card.

Alternatively you can issue short-lived certificates (RFC3980); in the case of windows it takes a mini driver to make your certificate look like a smart card token so it can be used for authentication. In the background you keep refreshing the certificate once in a while (1 week, 1 month, etc.) and pop up a web browser to a SAML re-authentication that proves you are still affiliated and authorized.

Classical OTP. You write a smart card, keep refreshing. You wrap that with a mini driver. From a tech perspective it will work, but from the administrative side: how will I make them available to people who have no or a minimal IT support.

The first time they log in you put up the regular authentication.

If you need other services like storage it’s reasonable to go for a Moonshot installation.

Project Moonshot-> www.project-moonshot.org

What is the current state of the Moonshot? The reason you don't see a lot of deployment is because only if you do windows to windows, there is a decent chance that Moonshot will work out for you.

The other option would be SPNEGO / Kerberos which would be an unworkable solution for most people due to configuration complexity.

HTTP Mechanisms

keybase.in? Doesn’t do SSH, SAML, OIDC, X.509

New HTTP mechanism would be better than password.

In the case of IoT authN/authZ you can look for IRTP ACE working group

In general the non-web HTTP authentication has not found its way to standardisation 5 years ago and now days all you have left is resort to ugly hacks. Today what you will do is maintaining ugly hacks.

Non-web SSO

Some tools are only available from the command line. When on Linux, solution is relatively easy. Some are only accessible on Windows. This becomes hard.

SAML ECP supported by Shibboleth.

How many use cases are not SSH? There’s is one: RDP

SSH key management could be a solution (80%).

  • Not cheap for users.
  • Users don’t always understand PKI
  • Infrastructure to generate an SSH key
  • Local trust is always easier than remote trust.


SPNEGO, FIDO, SAML ECP -> most likely only password based -> means maintaining large password stores in your infrastructure.

Challenge: getting users to accept new software on their machine.

IoT changes the need for non-web, i.e. non-HTTP, authentication.

“Our” needs for standard are relatively small compared to the “rest”. Makes our influence small.

LDAP Provisioning:

  1. create user account
  2. store given SSH public key