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]
Sent: Wednesday, 19 February 2014 11:50 p.m.
To: Colin Wallis
Cc: trust-el@lists.oasis-open.org
Subject: Re: [trust-el] RE: For Shaheen: RE: [trust-el] Notes from Jan 22 call.

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.

Don Thibeau

The Open Identity Exchange

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]
Sent: Saturday, 8 February 2014 4:56 a.m.
To: Colin Wallis
Cc: Mary Ruddy; 'Barbir, Abbie'; 'Peter Alterman'
Subject: RE: For Shaheen: RE: [trust-el] Notes from Jan 22 call.

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

We see every transaction as a relationship. We are JPMorgan Chase

PLEASE USE MY CHASE EMAIL ACCOUNT FOR ALL CORRESPONDENCE

<snip>

trust-el message