> I think that it is part of the protocol. I'm saying that we don't define > any authentication mechanisms, but we do allow the parties to > say which they can do, and which they are willing to accept. > > In dmd1 a HS advertises it's capabilities, which might include > the authentication mechanisms it supports, and a MS can > decide whether to accept assertions from that HS or not.
In DMD1 (Section 5.10.1.5) there is mention of an authentication requirement scenario but it kind of leaves negotiation out of the discussion. Unless you mean that member sites individually dictate authentication requirements every time a fetch-request is made? DMD1: dix://crypto-doodes.com/dongle#5 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Merrells Sent: Wednesday, January 18, 2006 6:08 PM To: Digital Identity Exchange Subject: Re: [dix] Re: attribute assertions On 18-Jan-06, at 5:39 PM, Suresh Venkatraman wrote: > The question was validation of the ID-server or "homesite" in DMD1 > terminology; as in does DIX provide a mechanism to validate or > assert that > the "homesite" is in fact who/what it says it is. This is probably > outside > the scope of DIX and is better left to the TLS/SSL layer. I think so. In dmd1 we have message verification, which just checks that a msg was sent from who says they sent them... which is no more secure than DNS. If you want assertions about the server identity then that's something you could layer on top. I think of that as 'Trust' though, maybe you don't. > >> Out of scope for how authentication is done... but in scope for how >> a membersite might require a certain level of authentication to be >> performed >> >> In dmd1 we don't specify any authentication mechanisms and we >> have the capabilities for declaring how auth could be done... and >> we have some thoughts around how a membersite could make >> assertions about its requirements. > > Is there a specific reason why negotiating the authentication > mechanism > should not be part of the protocol? Is it assumed that > authentication will > be addressed in the particular binding (HTTP, etc.)? We wouldn't > need to > make one up, just allow choice from the existing authentication > schemes. I think that it is part of the protocol. I'm saying that we don't define any authentication mechanisms, but we do allow the parties to say which they can do, and which they are willing to accept. In dmd1 a HS advertises it's capabilities, which might include the authentication mechanisms it supports, and a MS can decide whether to accept assertions from that HS or not. John _______________________________________________ dix mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/dix
