Re: Cross-organizational ACs

[Denis Pinkas <[e-mail]>]

Steve,

Since I am answering to the e-mail one by one, here is another comment.

> Stephen Farrell wrote:
> > > So I suggest that we omit AAControls from ac509prof.
> > > It adds substantial complexity with little value.
> >
> > It doesn't add any complexity since its in the "optional
> > to implement" section, just like attribute encryption. So,
> > if you want to, do it, if not, not. I think this was the
> > concensus of the WG at a number of meetings and on the
> > list discussion on the various revs of the I-D.
> 
> It adds complexity to the spec. This makes it more difficult for
> implementers to decide what to implement. And, if they decide to
> implement this optional feature, it adds complexity to their
> implementation. It also makes it more difficult for customers to decide
> which features they need (since they will probably consult the RFC for
> guidance). IETF specs (especially a profile!) should be as simple as
> possible, but no simpler.
> 
> I just wanted to point out that AAControls is not sufficient for
> cross-organizational ACs. If the consensus of the working group remains
> to be that the AAControls extension is still valuable,
 
Besides Stephen (and possibly the co-editors), it would be nice to know who
is (or is not) in favour of AAControls.

> I will certainly
> accept this judgement. If there is a sudden flurry of emails saying
> "take it out," that's fine with me, too. In either case, I will not
> implement AAControls myself. 

The same for me. :-)

> And I will work on and think about a
> simplified version of X.509 delegation that could be included in a
> future AC profile.

If you plan to attend the next IETF meeting, I would like to have a chat
with you, so that we can possibly define such delegation schemes. No syntax
changes planed in the definition of ACs, simply the definition of rules on
how to use them in the context of delegation.

Denis

 
> -Steve