[OGSA-AUTHZ] Implementations

[Tom Scavo]

On Sat, Mar 22, 2008 at 5:44 AM, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
>
>  ...the inclusion of a "certificate" needs more elaboration. The
>  inclusion for example of a user's public key certificate proves nothing
>  more than the presence of a DN does, since it is publicly available and
>  an untrustworth grid SP could send any PKC it wished, just as it can
>  send any DN it wished. Therefore one needs to specify the properties of
>  the certificate that are being transferred, which is, that the user is
>  delegating to the grid SP to act on its behalf. A proxy certificate
>  would do this, as would an attribute certificate.

I totally agree.  Of course this requires a new attribute request
handler at the Shib AA but then a new handler is required for a bare
DN as well, so there's no additional penalty.  I don't know that much
about the VOMS AA, but I'd be surprised if handling a full certificate
turned out to be much of a problem for VOMS.

We have a dilemma, however.  A formal ballot is currently underway to
promote the OASIS SAML V2.0 Deployment Profiles for X.509 Subjects to
Committee Specification status.  I fully expect this ballot to
succeed.  The next step after Committee Specification is OASIS
Standard (but this last step requires three attestations, which is
unlikely).

If we introduce a normative change to the profile such as we've been
discussing, we essentially start over.  Presumably the profile could
travel faster through committee this time around since the bulk of it
has already been vetted, but a significant delay is inevitable.

The other alternative is to specify this new extension of
saml2:BaseIDAbstractType in our Attribute Exchange profile and leave
the OASIS profile alone, flawed as it is.  A third alternative is to
do nothing.

I'm not sure what to recommend.  I'll let others comment on the
appropriate course of action.

Tom

>  Tom Scavo wrote:
>  >
>  > Instead of *requiring* a DN, the name identifier in the query should
>  > be generalized to accommodate the entire certificate (without
>  > excluding the possibility of a naked DN in those situations where it
>  > is warranted).  This can be done using <ds:KeyInfo>, something like
>  > this:
>  >
>  > <saml:Subject>
>  >  <saml:BaseID xsi:type="KeyIdentifierType">
>  >    <ds:KeyInfo>...</ds:KeyInfo>
>  >  </saml:BaseID>
>  > </saml:Subject>
>  >
>  > where KeyIdentifierType is defined as follows:
>  >
>  > <complexType name="KeyIdentifierType">
>  >  <complexContent>
>  >   <extension base="saml:BaseIDAbstractType">
>  >     <sequence>
>  >       <element ref="ds:KeyInfo"/>
>  >     </sequence>
>  >   </extension>
>  >  </complexContent>
>  > </complexType>