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

[Rhys Smith <Rhys.Smith AT jisc.ac.uk>]

Hi all,

I’ve had a quick scan through the policy and MDRPS and have the following 
feedback. As it stands, I feel this policy & MDRPS needs a fair amount of 
work doing to it before I would consider voting positively for it. Note that 
this is just a start, and once the following was dealt with I’ll have to have 
another more detailed look.



MDRPS:

1) MDRPS has "An Identity Provider (IdP) is an organisation or institution 
[…]” and “A Service Provider (SP) is an organisation or institution […]”.

-> These are the not the traditional definitions of an idP and SP, which are 
usually software installations fulfilling the IdP/RP roles of the SAML spec. 
An organisation/institution may wish to deploy an IdP/SP. Additionally, this 
doesn’t allow for an organisation to deploy both an IdP and an SP?


2) MDRPS says that an institution has to declare that its "processes are 
ready for inter federation”, but I can’t see anywhere where the specific 
requirements are that these processes must meet?


3) Approval for an organisation to join requires elements and attributes to 
use a domain name of that institution. This needs to be more specific and 
talk about what elements - entityID? Web service URLS? Anything else? And 
attributes do not use a domain name, apart from in scopes. If scopes are what 
is meant, they should be called out, as what the policy says as the moment, 
for example, is that passing across a “cn” attribute wouldn’t be allowed 
since it doesn’t use a domain name of that institution.


4) "The administrators appointed specifically by that institution would then 
get an access to the  metadata m anager service where they would upload the 
metadata of the their IdP. “ 

-> lack of consistency. Up until this point in the document, an “IdP” is an 
organisation, but now it’s a SAML entity.


5) "Subsequent changes to these elements and attributes do not require 
re-approval by the federation operator.”.

-> So an organisation can join with an entityId of their own domain, and then 
change it without approval to https://www.microsoft.com/ ?


6) What does "In RIF , no metadata gets modified because the federation 
operator generates it on behalf of all entities.” mean?


7) There’s no mention of how domain names/scopes are vetted, and what the 
policy is regarding entityId naming.



Policy doc:


1) As Guy said, technology profiles are mentioned and no such SAML technology 
profile is evident. Ditto assurance profiles.


2) "Identity Providers MUST generate and provide various Attributes as 
defined by the RIF , and as may be required by different Service Providers.”

-> So an organisation running an IdP has no choice on what attributes are 
released to an SP? Any SP can come along and demand that the IdP releases any 
attribute it wants?


3) "Only with the recorded permission of the End User may Identity Providers 
release Attributes to another Identity Provider, or a Service Provider.”

-> What’s meant by “recorded permission”.

-> Also, IdPs never release attributes to other IdPs.


4) "End Users who are no longer permitted access to the RIF must be revoked 
promptly”

-> That’s a bit harsh, I would suggest you just revoke their credentials 
instead...


5) "No Attributes must be generated and provided for such users to other RIF 
members.”

-> If their credentials have been revoked, they’d be unable to sign in and so 
this sentence is redundant.


6) "In the event that an End User’s status changes , the relevant Attributes 
and any other related information must also be changed as soon as possible, 
and all necessary communications must be made to all affected parties .

-> What’s a “necessary communication” here? Are you expecting that any time a 
user’s details change in any way, all SPs are notified? That doesn’t seem 
scalable.


7) "In the event that an End User transfers to another Identity Provider, 
their previous Identity P rovider must provide a mechanism for transfer of 
certain important A ttribute values”

-> If you’re going to require something like that, you need to specify what 
“important values” are.



Best,
Rhys.
--
Dr Rhys Smith
Chief Technical Architect, Trust & Identity
Jisc

T: +44 (0) 1235 822145
M: +44 (0) 7968 087821
Skype: rhys-smith
GPG: 0x4638C985
Lumen House, Library Avenue, Harwell Oxford, Didcot, OX11 0SG

jisc.ac.uk

Jisc is a registered charity (number 1149740) and a company limited by 
guarantee which is registered in England under Company No. 5747339, VAT No. 
GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, 
Bristol, BS2 0JA. T 0203 697 5800.

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