Strong Authencation (was [PROPOSAL] authentication age
Granqvist, Hans
hgranqvist at verisign.com
Fri Oct 6 16:21:13 UTC 2006
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
>
>
More information about the specs
mailing list