[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [trust-el] RE: For Shaheen: RE: [trust-el] Notes from Jan 22 call.
Well..there’s a kind of a generic answer that goes along the lines of..
...FIDO is building for always-on devices. It is natural that a user with such a device, has a number of services that they are logged into (at LoA1 in all probability) or
sitting at the front door of. FIDO want to see users have a seamless experience, and get access to the services they want (which will be mostly LoA2 and 3), quickly. For security reasons you really don’t want the user logged in all day at a higher LoA than
needed for the service they used for just 2 minutes, so to me that shouts ‘step up and step down Authn’. UAF and U2F are different in that U2F builds a second factor (device like a Yubikey) on top of username/pswd, while UAF uses the biometrics on a mobile (or so it seems from
the simple use case). With LoA2 and 3 being ‘that simple’ my sense is that access to higher LoA’s will not be seen as an impediment any more, so there will be multiple steps up and step downs per user in accessing those services/RPs supporting he FIDO protocols.. It’s early days for FIDO and I could have read this wrong but... Cheers Colin From: Don Thibeau [mailto:don.thibeau@openidentityexchange.org]
Colin: Please elaborate on your note below: It feels to me that RPs wanting to leverage FIDO would really expect it to do Trust-El pretty much out of the box. On Feb 18, 2014, at 7:09 PM, Colin Wallis <Colin.Wallis@dia.govt.nz> wrote:
OK, so I’ve had a quick second look (well after the event now), at Shaheen’s first pass at this..
Slide 2: what we have considered so far: (and these need to be frameworks, not specs like SAML.. Hmm OK ... So I think Shaheen said he would take a look at WS Trust and make a call there. With
the FIDO Ready specs coming out for review I guess we could ask the same question. My sense is that FIDO has a framework implicitly, but what we see is the specs because the pressure of time has seen those released first, before a ‘framework’. It feels to
me that RPs wanting to leverage FIDO would really expect it to do Trust-El pretty much out of the box..
Slides 5 and 6 are artefacts from our Deliverable 3 (Pages 6 and 25 respectively). So Slide 6 (Trust-El Use case sequence) doesn’t have a user consent step between the method query going to the
device and the method answer responding from the device. That said, we did say in deliverable 3 that the binding between the device and the user was weak, and I vaguely recall a discussion about Privacy matters/User Consent being out of scope but I may have
that wrong.
Slide 9: TE Method Type Request. Maybe I’m missing something but as I look at the XML in there, it doesn’t actually indicate a <type>. I guess I was expecting to see some kind of element name and
an attribute like ‘have’ (Yubikey) or ‘know’ (OTP, my favourite dog’s name) or ‘are’ (here’s my fingerprint). SAML has attribute types we could re-use and add others? Maybe Shaheen’s dots between the angle brackets is as much an indicator of the work ahead
of us, as the fragments of XML he has surfaced... J
Ramblings..lunch break is over..
FWIW anyway..
Cheers
Colin
From: AbdulJabbar,
Shaheen [mailto:Shaheen.AbdulJabbar@chase.com]
Hi Colin,
We were expecting your review comments on https://www.oasis-open.org/apps/org/workgroup/trust-el/download.php/52039/Trust%20Elevation%20Spec%20v0_1.pdf.
I believe you also have comments with SAML in perspective.
Shaheen Shaheen Abdul Jabbar CISSP,
CRISC | Information
Risk Manager | Application Security | SSAP | Chase Commerce Solutions | Paymentech | 4 Northeastern Blvd, Salem, NH 03079 | ( +1
603 896 8171 | shaheen.abduljabbar@chase.com We see every transaction as a relationship. We are JPMorgan Chase PLEASE USE MY CHASE EMAIL ACCOUNT FOR ALL CORRESPONDENCE
<snip> |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]