RE: [UC-1-04:ARundgrenPush]

[Darren Platt <dplatt@securant.com>]

I think Bob Morgan was right to point out how 'loaded' the term
'authentication' is, and so I think we should be very clear about the
different ways we are using that term.  I see 3 ways currently (I'll give
them some crummy names for now for the sake of discussion) - 'end user',
'domain to domain', and 'peer to peer'.

'End user' authentication is where one security domain asserts to another
security domain the fact that an authentication event took place related to
a specific user.  When authC types are discussed in this context, they
pertain to types of authentication an end user has presented to authenticate
themselves to the security domain.  So far there is some agreement that 'end
user' authC should be part of the specification.  In my opinion, the 'end
user' authentication information should be considered part of the session
information (ISSUE:[UC-3-01:UserSession]) to be shared between security
domains.

The 'domain to domain' authC being discussed is between the security domains
themselves in order to support UC-1.  There have been a few methods for this
discussed over the last few months - including using digital signatures,
2-way authenticated SSL, or encryption.  I recall some debate about the
advantages and drawbacks of each - mostly centered around performance
considerations.  I think this is the type of authC that Anders desires, and
would suggest that his requirement could be stated as something like 'When
providing the SSO behavior described in UC-1, use the validation of the
digital signatures of the assertions for the purpose of authenticating the
security domains to each other. ' + (privacy considerations requirements).

The third type of authC is where an actor provides credentials to a service,
which returns what is essentially an authorization assertion.  This type of
authC is where the 'challenge response' non-goal applies - that the service
not support that type of authC.  This is related to
ISSUE:[UC-4-01:SecurityService].

Perhaps if we frame the conversation this way, we can come to agreement to
some parts at least.

Regards,

Darren



> -----Original Message-----
> From: Orchard, David [mailto:dorchard@jamcracker.com]
> Sent: Monday, February 12, 2001 3:50 PM
> To: Evan Prodromou; S2ML-USE
> Subject: RE: [UC-1-04:ARundgrenPush]
>
>
> Evan,
>
> I completely concur with your opinion on this issue.  We do have a clear
> process to follow.
>
> We (Anders?) should write up a concrete use case, called something like
> "negotiate trust relationship between partners".  We should then
> discuss on
> the mailing list/concalls to make sure the use case is described
> enough for
> us to vote on.  We should then vote on the use-case.  My early
> prediction is
> that the use case will not pass muster - certainly a lot would have to be
> done to convince me to vote for it - but we will have followed the process
> and we will have useful artifacts for future work.
>
> Cheers,
> Dave
>
> > -----Original Message-----
> > From: Evan Prodromou [mailto:evan@outlook.net]
> > Sent: Monday, February 12, 2001 2:27 PM
> > To: S2ML-USE
> > Subject: Re: [UC-1-04:ARundgrenPush]
> >
> >
> > >>>>> "HL" == Hal Lockhart <hal.lockhart@entegrity.com> writes:
> >
> >     >> You also lack a business case.  Why do you need a particular
> >     >> business case when we are talking about extending the access
> >     >> system of practially all computer systems (but with arbitrary
> >     >> granularity and semantics) to function over the web between
> >     >> different, independent and constantly changing organizations as
> >     >> well?  IMO that's *hell* of a use case!  If it is a hell to
> >     >> design I am not yet able to tell.
> >
> > I'm replying to the wrong message, so, sorry.
> >
> > But I think Anders has gotten to the kernel of this issue. I think for
> > most of us with experience with AuthXML or S2ML, we've dealt from the
> > get-go with expecting peer security systems to have arranged their
> > partnership out-of-band. In other words, there are configuration
> > options on each piece of software that say what data is sent as
> > credentials, what profile information to share, what keys belong to
> > what security system, etc.
> >
> > We explicitly have this called out in the current doc, saying that
> > "trust negotiations must be made out-of-band." I agree with Anders
> > that there's a momentous opportunity in dropping this non-goal and
> > allowing the trust relationship to be negotiated IN-band ("Who are
> > you? Who says that's you? What do you want?").
> >
> > However, I am extremely leery of this expansion of scope. I wonder if
> > there's an opportunity here to stow away this use case and use it for
> > a next version of [OSSML] or for even another effort of this
> > TC. Something that operates well with what we do, but not part of this
> > current effort.
> >
> > ~ESP
> >
> >
>