 |
 |
David, as far as the usability issue is concerned, it all depends on the COI's requirements, doesn't it? Would a moonshotted web-portal make it easier for users? Possibly. For realm-targeted IDs this is a lot easier, because you only need to know what the realm is (and either provide this in a drop-down or a list of COI member organisations) on the IdP side to generate the ID and display it. For RP-targeted IDs, every single RP would need to be known to the IdP (at Diamond for example, this would be every single server and workstation, which is totally unfeasible). Of course, if your COI only has a limited number of RPs, that could still be workable, but I'm sure Sam will have something to say about an IdP pre-generating IDs on the basis that the RP names are not sent by the RPs themselves, but are in a fixed/dynamically-populated list. That's one reason why I prefer a realm-targeted ID on the fundamental Moonshot level (on the APC level, if you will), it is sufficiently anonymous to not tell you who the user is, but sufficiently unique (when scoped to the RP's realm) to any resources at the RP's realm. The COI might decide that more specific IDs are required, but that's something for the COI to decide. Stefan -----Original Message----- From: David Chadwick [mailto:[log in to unmask]] Sent: 22 May 2014 12:44 To: Stefan Paetow; [log in to unmask] Subject: Re: Attribute filtering / access control with moonshot Hi Stefan given the difference between VOs and CoIs it would seem that the most useful place for the third identifier is at the VO level, where the user has an ID to identify him at all the resources in the VO. However, in our current work on VOs the main usability issue that arises with these type of IDs, is whether the user knows them beforehand or not. If the user does know his ID it makes setting up VOs easier. If he does not (e.g. because it is auto-generated) then it complicates the RPs use of them, because the access control rules have to be set up to incorporate them before they can be used effectively. regards David On 22/05/2014 11:34, Stefan Paetow wrote: > David, > > And those can all be shipped along in the SAML assertion that's part > of the RADIUS packet. > > Remember (from your discussion with Josh earlier this year) that the > fundamental difference between a VO and a COI is that a VO involves > itself with *identities* and *resources*, whereas a COI is a level > lower, and involves *services* which provide either resources or > identities. > > Stefan > > -----Original Message----- From: Moonshot community list > [mailto:[log in to unmask]] On Behalf Of David Chadwick > Sent: 22 May 2014 08:26 To: > [log in to unmask] Subject: Re: Attribute filtering / > access control with moonshot > > Rhys > > I think this is a good idea. I can see the logic in having all three, > i.e. a global id, an RP targeted ID and a CoI (or dare I say VO) > specific ID > > David > > > Janet(UK) is a trading name of Jisc Collections and Janet Limited, a > not-for-profit company which is registered in England under No. > 2881024 and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. > 614944238 > Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238