Hi Rhys,

I have a preference for option 1. This is a AAA architecture, and so we should use representations consistent with that, and map to alternative representations as necessary.

There is also value for an IdP in having the option to choose between releasing identifiers for realm and/or CoI. It is in effect a mechanism for the IdP to manage its tolerance of collusion between realms.

I also propose that we define a third opaque identifier targeted on the acceptor name of the RP. This addresses the case where the IdP is intolerant of collusion within a realm. So for opaque identifiers we have acceptor-targetedid, realm-targetedid, coi-targeted. We could even scope a fourth identifier to each service on an acceptor, although I'm not sure that makes sense. 

Josh.

> -----Original Message-----
> From: Moonshot community list [mailto:MOONSHOT-
> [log in to unmask]] On Behalf Of Rhys Smith
> Sent: 23 May 2014 09:21
> To: [log in to unmask]
> Subject: Re: Attribute filtering / access control with moonshot
> 
> On 22 May 2014, at 19:15, Sam Hartman <[log in to unmask]>
> wrote:
> 
> > I think for RADIUS, separate attributes will fit their model better.
> > But this is something to consider.
> 
> So we have two options for an opaque identifier:
> 
> 1) The two attribute option:
> 
> a) moonshot-realm-targetedid. Value a hash of Gss-Acceptor-Realm, NAI,
> salt. Representation: [log in to unmask] e.g. [log in to unmask]
> 
> b) moonshot-tr-coi-targetedid. Value a hash of CoI-Identifier, NAI, salt.
> Represented as [log in to unmask] e.g. [log in to unmask]
> 
> IdPs would release coi-based, or realm-based, or neither, based on policy.
> Could release both, of course, though not sure what the point of that would
> be.
> 
> 
> 
> or 2) SAML persistant-id-alike single attribute:
> 
> a) moonshot-targetedid. Value a hash of Gss-Acceptor-Realm OR CoI-
> Identifier, NAI,salt. Represented as {idp-realm}!{audience}!{value}.
> e.g. when the audience is the CoI -
> camford.ac.uk!pilot.communities.moonshot.ja.net!asdfghjkl
> e.g. when the audience is a gss-acceptor-realm -
> camford.ac.uk!someservicerealm.com!asdfghjkl
> 
> IdPs would release it or not, and choose which option to use, based on
> policy.
> 
> 
> Some considerations that spring to mind:
> 
> 
> In the first (two attribute) case:
> * recipients would check User-Name, then moonshot-tr-coi-targetedid, then
> moonshot-realm-targetedid, otherwise anonymous. More complex logic
> (more attributes to iterate through), but whether the ID is targeted at the CoI
> or at the realm is very explicit and easy to figure out.
> * Representation matches the way RADIUS normally does things.
> * IdPs have a simple attribute definition which generates the values for both
> attributes, and the policy lives at the point of release - which CoIs get to see
> the coi-targetedid, and which don't. Those that don't just get to see realm-
> targetedid, or nothing.
> 
> In the second (one attribute) case:
> * recipients would check User-Name, then moonshot-targetedid, otherwise
> anonymous. Simpler logic, but if you want to know whether you have an ID
> that is targeted at the CoI or at your realm, you have to do some work
> looking at the audience value to figure that out.
> * Representation matches the way SAML normally does things.
> * IdPs have a more complex attribute definition as the policy now lives on the
> point of attribute creation, but the release policy is probably simpler (either
> release it or nothing).
> 
> 
> Also, if we're then going to use these identifiers as a nameid when sending
> subsequent SAML assertion requests (as per what Josh said), in the first case
> we either have to define our own custom SAML name id format, or convert
> from the RADIUS representation to the SAML triple and use the persistent
> name-id format. In the second case we could just use it directly. (All
> potentially subject to mapping AAA names to SAML names? I'm still not clear
> on that bit of the puzzle yet...).
> 
> 
> Are there any other considerations or reasons to use one option over the
> other?
> 
> Rhys.
> --
> Dr Rhys Smith
> Identity, Access, and Middleware Specialist Cardiff University & Janet, the
> UK's research and education network
> 
> email: [log in to unmask] / [log in to unmask]
> GPG: 0x4638C985

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