OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Transport related authentication in CPA (was SSL Mutual Authenticationand the Message Service Spec)


Dan,

Thanks, I think that the "basic" and "digest"
may be a start at providing values for transport
level authentication, in addition to the
changes in CertRef  for Arvola's
client-side SSL/TLS authentication descriptions.

I am, however, concerned that 
we may need to add some more
information to reflect agreements
that nail down the factors needed for
interoperability for authentication at
"transport layers". 

For example, the "basic" authentication
scheme might be augmented by information
about the realm. For the "digest" authentication
scheme family, it looks like more mechanisms
have been added since rfc 2617-- e.g., those
of rfc 2831. Also, parameters like "qop-options" may
be used, and are consequently matters that
a CPA might specify, because an interop.
issue might stem from different capabilities
among implementations. Likewise, a server
may optionally choose to specify that
the authenticator use some other digest
algorithm than MD5, which might frustrate
interoperability. If we do decide to add
specifying these functions in version 1.1, we should have
a survey of specified and/or used-in-practice
mechanisms, and their parameters, whose
configurability or optionality may impede
interoperability.

I only "half follow" all the variants in
this area, and do not have a good sense
for what is really used in practice 
(especially for b2b communications)
and/or what is just specified in some rfc.
If someone could create a table/list/
/spreadsheet enumerating the existing
variants, and the optional parameters
in these variants, we could then proceed
to propose the additional elements and
attributes needed in CPPs and CPAs for
HTTP authentication. 

So, do we have voluteers?

Dale Moberg

-----Original Message-----
From: Dan Weinreb [mailto:dlw@exceloncorp.com]
Sent: Tuesday, August 28, 2001 9:55 AM
To: Dale Moberg
Cc: arvola@tibco.com; timothy.r.collier@intel.com;
ebxml-cppa@lists.oasis-open.org; ebxml-msg@lists.oasis-open.org
Subject: Re: SSL Mutual Authentication and the Message Service Spec


   Date: Tue, 28 Aug 2001 09:17:00 -0700
   From: Dale Moberg <dmoberg@cyclonecommerce.com>

   Is there a standardized way of referring to
   different HTTP auth mechanisms that we could reuse
   (like a URI, OID or whatever...)?

HTTP authentication mechanisms are identified by a token, found
in a "challenge", found in the WWW-Authenticate HTTP header field.
I think "basic" and "digest" are the only ones.  See RFC 2616.

-- Dan


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC