> I think an approach very similar to this would be fine.
> I think this sort of thing could go well in an APC policy statement.

If we're sticking to SAML-style identifiers, that would probably be perfectly acceptable. I don't see any problems with it :-)

> * CUI is based on Operator-Name.  It's much easier for us to base
>  something on Gss-Acceptor-Realm.

With the appropriate changes in policy.d this probably could be applied, i.e. if Gss-Acceptor-Realm is available, use it in preference to Operator-Name?

> * We want something that we can verify the scope of.  I think it is very
>   easy to misconfigure this if we re-use CUI and if we're careful in a
>   new attribute we can make that misconfiguration harder.  We can either
>   say that it's scoped by the IDP and scope is verified by the RP, or we
>   can say scope is added by the RP.

Ok, in that case this attribute will need to be decided fairly sharpish, so that it makes it into the FreeRADIUS dictionaries before the service goes live. The reason I say this is because you really don't want to have to tell people to fiddle with more configuration bits (like adding lines to dictionary files) when the service is live. The fact that I had to document this for FR 2.1.x filled me with dread and I was very relieved when RFC 7055 went in.

> Whatever, by the time it gets to the acceptor I think it's important
>   there be an explicit non-spoofable scope.

Non-spoofable technically, I hope!

> * We could do the above with CUI although we'd either need to mandate
>   that IDPs scope which removes a lot of the value of code re-use or we
>   would need to say that the RP scopes in which case we'd be violating
>   the CUI RFC by modifying the CUI in the RP proxy.

True. Which is the lesser of the two evils? If the policy.d/cui is modified to make the scoping at the IdP conditional on the receipt of GSS-* attributes (which will be the case in Moonshot RADIUS conversations), then the IdP can serve both Moonshot and non-Moonshot CUI. Just a suggestion :-)

> introducing real probabilities of insecurity.  If I'm missing something
> and there is a migration strategy that adds value, then re-use of CUI
> makes more sense to me.

Ok, fair enough. 

The sooner there's agreement, the sooner we can try this out :-)

Stefan

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