+1 to this approach. I'd agree with previously stated sentiments that HTTP auth is already well-defined elsewhere with finite set of specified options with pretty well-understood pros and cons w.r.t. usage and security, as well as the ability to be extended when the well-defined options don't meet requirements.
I think try to prescribe one particular option to fit all possible APP use cases as a minimal subset would be a mistake, whether it is BASIC, BASIC + TLS, or Digest. Server vendors (that exist so they can have/serve clients) will make good choices that balance making their services broadly accessible with providing appropriate guarantees of security for their services. Those that fail on either front won't get used, which seems punitive enough. RFC2617 defines a number of possible models for achieving this balance, and we should just point to it. Narrowing it or elaborating upon is has the potential to make APP less useful, not more so. What makes APP so unique from an HTTP interop or a security pespective that this would be justifiable? Cheers! -- Kyle On 2/23/06, James M Snell <[EMAIL PROTECTED]> wrote: > > Alternative approach to PaceBasicAuthentication and PaceAuthentication. > > http://www.intertwingly.net/wiki/pie/PaceFixSecurityConsiderations > > #pragma section-numbers off > > == Abstract == > > Remove section 13. Replace section 14 with a more generic statement > about APP being subject to the same security considerations as RFC2616 > with a constraint that if Basic Auth is used, TLS SHOULD also be used. > > == Status == > > Proposed > > == Rationale == > > APP is an HTTP spec. HTTP already has defined authentication > mechanisms. There is no need for APP to specify specific authentication > mechanisms. CGI authentication is valuable, but best done as a separate > spec deriving from RFC2617. > > == Proposal == > > Remove section 13. Replace section 14. > > {{{ > 14. Security Considerations > > Implementations of the Atom Publishing Protocol SHOULD be protected using > HTTP Authentication mechanisms as defined by or derived from [RFC2617]. If > implementations choose to implement support for HTTP Basic Authentication, > they SHOULD support encryption of the session using TLS [RFC2246]. The > security of the Atom Publishing Protocol is subject to the same security > considerations as discussed in [RFC2616] and are entirely dependent on the > strengths and weaknesses of the implementation and chosen authentication > and > transport security mechanisms. > }}} > > == Impacts == > > > > == Notes == > > > ---- > > CategoryProposals > >
