>>>>> "Stefan" == Stefan Winter <[log in to unmask]> writes:

    Stefan> So, what is wrong with taking the CUI as per RFC, extracting the value,
    Stefan> adding the two-tuple of IdP and RP to it, plus requiring sth like "In
    Stefan> addition to the requirements as per RFC, CUI values which are used in a
    Stefan> Moonshot/ABFAB context MUST NOT be re-used."

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.

I would prefer that we use a different attribute for the following
reasons:

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

* 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.
Whatever, by the time it gets to the acceptor I think it's important
  there be an explicit non-spoofable scope.

* 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.

So, in summary, I have no problem with starting with CUI.  I don't
personally think it buys a pure Moonshot community anything.  The code
on the IDP needs to change to use something more moonshot-friendly than
Operator-Name, and the code on the RP needs to change to verify scope.
So since changes are needed on both sides re-use doesn't seem to have
huge value.

I agree that CUI is a useful thing to be using today.  I explicitly want
to break compatibility with that when we move to something pure moonshot
because I don't see a way to maintain that compatibility without
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.