Strong Authencation (was [PROPOSAL] authentication age

Fri Oct 6 23:37:20 UTC 2006

Thanks, Hans, I'm getting better educated on 2.0 every day.

=Drummond 

-----Original Message-----
From: Granqvist, Hans [mailto:hgranqvist at verisign.com] 
Sent: Friday, October 06, 2006 9:21 AM
To: Drummond Reed; Chris Drake
Cc: specs at openid.net
Subject: RE: Re[2]: Strong Authencation (was [PROPOSAL] authentication age

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: specs-bounces at openid.net 
> [mailto:specs-bounces at openid.net] On Behalf Of Drummond Reed
> Sent: Thursday, October 05, 2006 2:26 PM
> To: 'Chris Drake'
> Cc: specs at 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:christopher at pobox.com]
> Sent: Thursday, October 05, 2006 10:51 AM
> To: Drummond Reed
> Cc: specs at 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: specs-bounces at openid.net
> DR> [mailto:specs-bounces at openid.net] On Behalf Of Dick Hardt
> DR> Sent: Thursday, October 05, 2006 9:36 AM
> DR> To: Gabe Wachob
> DR> Cc: specs at 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: specs-bounces at openid.net 
> [mailto:specs-bounces at openid.net] On 
> >>> Behalf Of Chris Drake
> >>> Sent: Wednesday, October 04, 2006 8:26 PM
> >>> To: Kevin Turner
> >>> Cc: specs at 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 at openid.net
> >>> http://openid.net/mailman/listinfo/specs
> >>
> >> _______________________________________________
> >> specs mailing list
> >> specs at openid.net
> >> http://openid.net/mailman/listinfo/specs
> >>
> >>
> 
> DR> _______________________________________________
> DR> specs mailing list
> DR> specs at openid.net
> DR> http://openid.net/mailman/listinfo/specs
> 
> DR> _______________________________________________
> DR> specs mailing list
> DR> specs at openid.net
> DR> http://openid.net/mailman/listinfo/specs
> 
> 
> 
> 
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
> 
> 