I think the 2.0 spec extension mechanism could handle signed credentials. For example, "credentials=<s>" where <s> is of a (string) format that contains a type + signature, say
credentials=OATHVIP:WW91IGhhZCB0byBjaGVjaywgZGlkbid0IHlvdT8gOyk= The format could also further specify mechanism types, signer identity, and algorithm(s) used if those are not part of the definition of 'credentials'. Hans > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Drummond Reed > Sent: Thursday, October 05, 2006 2:26 PM > To: 'Chris Drake' > Cc: specs@openid.net > Subject: RE: Re[2]: Strong Authencation (was [PROPOSAL] > authentication age > > Chris, > > Great examples. Signed credentials makes lots of sense. > OpenID AuthN 2.0 doesn't handle them yet but I can completely > understand them in the roadmap. > > =Drummond > > -----Original Message----- > From: Chris Drake [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 05, 2006 10:51 AM > To: Drummond Reed > Cc: specs@openid.net > Subject: Re[2]: Strong Authencation (was [PROPOSAL] authentication age > > Hi Drummond, > > Example1: RSA would provide a signed response indicating that > the user correctly entered the SecurID token code. > > Example2: The RP would have the public key of the company > that supplies the fingerprint scanning hardware (although > some extra thought as to how a fingerprint ultimately matches > to an Identity is required, which will need an entirely > different information flow to Example1). > > Is Dick a vendor himself? he no doubt knows other ways. > > Kind Regards, > Chris Drake, > =1id.com > > > Friday, October 6, 2006, 3:19:44 AM, you wrote: > > DR> Dick, > > DR> You say, " The strong authentication will be supplied by a vendor > DR> that > has > DR> been certified to provide standardized levels of > authentication. The > DR> IdP will often NOT be the strong auth vendor." > > DR> Can you explain how this might work, i.e., how can the RP have a > DR> relationship directly with the strong auth vendor and not > the IdP? > DR> Would > the > DR> IdP be outsourcing authentication to the strong auth vendor? In > DR> which > case, > DR> isn't the strong auth vendor the IdP? > > DR> =Drummond > > DR> -----Original Message----- > DR> From: [EMAIL PROTECTED] > DR> [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt > DR> Sent: Thursday, October 05, 2006 9:36 AM > DR> To: Gabe Wachob > DR> Cc: specs@openid.net > DR> Subject: Strong Authencation (was [PROPOSAL] authentication age > > DR> The vision I have is that strong authentication to your > IdP will be > DR> common in the future. > > DR> The strong authentication will be supplied by a vendor > that has been > DR> certified to provide standardized levels of > authentication. The IdP > DR> will often NOT be the strong auth vendor. > > DR> The RP will have a trust relationship with the vendor, likely > DR> through a vendor consortium that delegates to vendors that their > DR> product is certified, ie. the RP will not need to trust > each vendor, > DR> just the certification body. > > DR> I would hope that OpenID can be extended over time to be able to > DR> move around these types of strong auth assertions. > > DR> -- Dick > > > DR> On 4-Oct-06, at 8:41 PM, Gabe Wachob wrote: > > >> Chris- > >> As someone who has recently come from working in the financial > >> sector (Visa), its clear that OpenID is NOT intended for > >> authentication where the *relying party* cares about how the > >> authentication is performed. > >> > >> At places like Visa and for home banking, this means > that OpenID, > >> without something more, is clearly a non-starter. These relying > >> parties want to know exactly how their users are being > authenticated > >> because their business is all about risk management and creating > >> business opportunities around very good knowledge of the > risk profile > >> of each transaction type. > >> > >> That all being said, I believe it should be possible to > layer on > >> OpenID a form of IDP control such that a relying party can > require a > >> certain class or group of IDPs be used when presenting > authentication > >> assertions to them. The actual *policy* for how these IDPs are > >> approved is probably orthogonal to the protocol spec, but "secure" > >> identification of those IDPs (relative to some trust root, > etc) could > >> probably be made into an extension usable for those > parties who want > >> it. > >> > >> My guess is that culturally, most people involved in OpenID have > >> *not* been interested in addressing these concerns. However, > >> expectations need to be better managed around these sort of > >> "relying-party cares" > >> scenarios, because its not obvious without actually > reading the specs > >> themselves... > >> > >> -Gabe > >> > >>> -----Original Message----- > >>> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > >>> Behalf Of Chris Drake > >>> Sent: Wednesday, October 04, 2006 8:26 PM > >>> To: Kevin Turner > >>> Cc: specs@openid.net > >>> Subject: Re[2]: [PROPOSAL] authentication age > >>> > >>> Hi Kevin, > >>> > >>> Sounds like you're leaning towards a root authority for > IdPs who can > >>> audit procedures and verify protection in order to sign the IdP's > >>> keys? > >>> > >>> Joe blogger doesn't care much about identity assertions > from an IdP, > >>> but it's a reasonable bet to expect that a Bank might care... > >>> > >>> Kind Regards, > >>> Chris Drake > >>> > >>> > >>> _______________________________________________ > >>> specs mailing list > >>> specs@openid.net > >>> http://openid.net/mailman/listinfo/specs > >> > >> _______________________________________________ > >> specs mailing list > >> specs@openid.net > >> http://openid.net/mailman/listinfo/specs > >> > >> > > DR> _______________________________________________ > DR> specs mailing list > DR> specs@openid.net > DR> http://openid.net/mailman/listinfo/specs > > DR> _______________________________________________ > DR> specs mailing list > DR> specs@openid.net > DR> http://openid.net/mailman/listinfo/specs > > > > > _______________________________________________ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs