Identity

<scribe> Scribe: Josh_Soref

Mani: I suggested this session
... in the last two days of discussions in WebRTC
... the one problem that came up was
... the notion of how one UA talks to another UA
... how does a UA know it's talking to a UA it wants to reach
... there's the notion of an identity provider
... What is the easiest way to validate that an incoming call
... is coming from a certain identity
... there's OAuth
... and similar
... there's the notation of Browser ID from Firefox
... I believe it provides a more portable way
... to validate yourself
... but the challenge is which will really stick
... the other question is
... when this gets deployed within enterprises
... how will enterprises facilitate distributing this to remote entities
... federation
... that's an implication that some federation model is needed
... there's federation in Real Time Communication space
... there's some work in IETF
... that's where I thought we'd start the discussion
... this area is emerging from WebRTC space
... a portable identity that doesn't require the user to be frequently prompted for consent before communication
... I'm waiting for feedback / additional thoughts

[ The floor is open ]

RogerC: Roger Cutler, Chevron
... I don't know much about these things
... I don't know what authority these would be based on

Mani: You mentioned the need for an authority
... there doesn't need to be a single one
... there can be a bunch with some higherarchy
... delegation
... OpenID is one kind of framework that allows this
... - you can perform an authentication
... in one space which is recognized in other spaces
... I have a Yahoo identity
... and other identities
... I don't want to sign in for each of them
... There's a service provider
... and in turn, providers talk to the credential provider

CullenJ: Cullen Jennings, Cisco
... we have these names like fluffy@cisco.com
... there's rooted, someone allocated them to us
... they're sort of an identity you can use
... and you sort of have to trust the provider who gave you your name
... because they can take away your name
... you don't want to have one name for all services you use
... it's convenient to have a handful of names
... it's common to use Facebook Connect or Gmail

<inserted> a framework to connect

CullenJ: OAuth or others
... they deal with a user passing authentication to a site
... in the UC here, you have two users wanting to share
... and they want to trust a site to decide they trust users
... but they don't want to trust that site with their content
... f.ex. WebEx
... they want to use it to identify users
... but not share their content to WebEx
... How do we do that?
... one person might talk to an identity provider
... and get a token which is limited to for a single target user
... does that make sense?

[ Yes ]

RogerC: isn't there a spec for this?
... SAML?

CullenJ: Sure
... that's one of them

Zakim: q+ betehess

scribe: SAML is one, OpenID another, mozilla's thing

<betehess> Zakim: this is identity

scribe: SAML seems to be replaced rapidly by OAuth

<betehess> ashok speaking

[ AshokMalhotra confirms that OAuth is winning ]

<betehess> Zakim: ack next

betehess: Alexand betehess, W3C
... We discussed this yesterday
... on Federated Social
... the discussion was on 2 things:
... 1. Crypto API
... - how to improve it in UAs and how to standardize it
... 2. Identity
... - how do we speak about identity
... The discussion was about browser
... others said what about other UAs?
... what about other things on the web?
... this was one of the things that was not solved yesterday
... but it's in the Charter
... I'm very interested in this work
... I'm implementing a Read Write Linked Data protocol
... we need to be able to speak about identity on the web
... we don't know if Email is the common identity to speak about on the web

[ Mani draws a diagram ]

Mani: a user specifies
... that he's belonging to alice@gmail.com
... and this is bob@yahoo.com
... associated with two different identity providers
... the model isn't different from what SAML talks about
... we still have the same problem
... the ability to say:
... you are going to communicate to this
... at some point, there's an attempt to reach the other end
... there's going to be a need to confirm the identity
... in a trustable fashion
... so yahoo can assert that alice@gmail.com is that entity it claims to be
... when there's a trust framework such as OAuth that operates between Gmail and Yahoo
... it means every time when you try to make this connection
... there's a requirement to get user consent
... and each prompt
... is for a limited session
... or it may be for a longer period
... but then it needs to have enough security built into the system so that it isn't compromised
... there was also a discussion about long term vs. short term access
... before we go into this, we want to know if this is the easiest model
... I don't know enough about Browser ID
... An Identity Provider such as Gmail/Yahoo can digitally sign something
... which can be embedded in the browser
... so the user doesn't need to be logged into the domain
... and it can then do direct validation
... without involving the online identity provider
... not requiring the identity provider to be inline
... i'm not sure i communicated that properly

betehess: that can work, but it's browser centric, and requires a provider
... a browser identifies someone using an email
... communication with someone, even email based

Mani: another question is
... what happens for something which is validated
... if the device with the id is stolen
... what happens isn't very clear in my mind
... Is the relevant models satisfactory
... does it meet the needs of the Provenance model?
... is it feasible?

AshokMalhotra: you said that something can assert that someone is alice@gmail.com

TimT: Tim Terriberry, Mozilla
... it may be just to say this user has this email id

AshokMalhotra: so you're not talking about verifying that that's the person

PhilipG1: Philip Gladstone, Cisco
... I still have certificates that I continue to renew that show I work for companies i don't work for anymore
... I've worked for a number of companies since the mid '90s
... you can assume that i once worked for Cisco

fluffy: you can look at the liveness of the item
... and assume it was true when it was issued
... These kinds of systems will need to deal with that
... because it will be necessary to revoke
... The other kind I'm interested in is phone numbers
... You can receive a phone call or an sms
... And certainly not assert the CallerID

betehess: I'm not sure we have an answer to what Identity is really about
... For some things, it's "something that can answer to an email"
... but if it's a machine?
... it can't be only that
... Thoughts?

[ CullenJ = fluffy ]

fluffy: Example: Email
... if the mailing list bot responds to you, it's basically a machine
... but it still has a name
... Whether you're talking to a machine, bot or human,
... maybe there's less of a difference between them

betehess: what's the use case?
... does it still apply for machines?
... what's the common denominator on the web?
... for me it's an http uri

fluffy: a possible definition is that
... a person can cryptographically prove
... that they can manipulate content at that URI
... given the way we use URIs
... it may be hard
... but it's possible to do something along those lines
... with email, you can prove that you can receive email there
... with http, you can prove you own it, by showing that you can manipulate it

betehess: sounds good

<Zakim> betehess, you wanted to question people about what they believe identity is about

AshokMalhotra: you said
... that's not all it is
... [ references "it can't be only that" ]
... but I think that's all it is

<betehess> Virginie from Gemalto speaking

Virginie: Virgine from Gemalto
... you need to have one single entrypoint
... which can be a URI
... and after that you can have a thing which is profiled
... if you have a unique need to identify a machine/etc.
... you get a URI
... after that, you get a profile, which is more flexible
... a thought from a company providing SIM cards, identity cards

AshokMalhotra: this is where you go towards
... clarification that "this is that person, the guy with the card"
... but this is not talking about that, it's talking about
... "this is a token" that lets you prove certain things
... it has nothing really to do with you

RogerC: I don't know if this is out of line
... my step father, who is kind of old, he will apparently click on anything

[ Laughter ]

RogerC: I get things that are authentically from him
... Is there a way to prove that things are intentionally from someone?

Mani: there's a thing Yahoo uses
... which many email providers use

AshokMalhotra: you can sign stuff

RogerC: it would be unpleasant
... but a mail client could spit back a captcha or similar
... before it sent mail
... But phishing is not a good thing, it's a big problem

<AshokMalhotra> ... but no one signs mail

Mani: sure phishing is a problem
... but you can verify that mail from yahoo.com is from yahoo.com
... and you can decide that xx@yahoo.com is really xx@yahoo.com according to yahoo.com

Virginie: I'm new to W3C
... I'm coming from my background of smart card
... making sure you reached the target
... and authenticating
... and then being able to better know the target
... it seems we're meandering from one thing to another
... either we have information exchange
... or make the picture clearer on each of the topics i mentioned

betehess: maybe we need definitions on these things
... we all have some understanding of what it is about
... this is people's real business
... can we define the three terms?

Virginie: the way we do it is mostly proprietary technology
... it would be hard for me to go to a pure abstraction
... 1. Target
... - who do you want to talk to/ where do you want to talk to'
... we do not use URI at Gemalto
... 2. Authentication
... - and you mentioned several protocols
... direct, or delegated

<fluffy> Mani is gentleman that gave the problem statement at start

Virginie: 3. Profile
... - all the different attributes you may associate with your target
... for a mobile operator's customers
... a. the subscription
... - your actual phone number
... b. the over the air technology
... c. the content of the SIM card
... - which applications are inside

Harry: hhalpin, W3C
... we believe it or not held a workshop on this topic during the end of May
... in Mountain View
... where we invited W3C members to attend
... there's OpenID connect, OAuth
... and a lot of our membership is happy with SAML
... what we found was the lack of support for crypto
... at the last breakout session we were trying to determine
... we believe the Browser vendors are interested in standardizing the crypto apis
... a lot of people have talked about uris/identity
... there's very little progress, minus the failed info-card element
... is the progress on the client
... at our last breakout session is a Charter for WG work in this Domain

betehess: if people try to define these terms
... these are the things we have to define first
... and then think about the technolgoies
... most of the times, people don't seem to be talking about what they're solving

hhalpin: it's pretty clear that Identity leads to confusion
... what's agreed on is Authorization
... e.g. OpenID lets you authorize and get redirect and carry a token
... the actual space: <long-list> is well understood
... that part is consistent between specifications

betehess: I think it might be a good idea to standardize these terms

hhalpin: we can determine these terms in our specifications
... and follow best practices from the larger communities in this area
... such as kerberos 1
... and we don't want to invent new terms

fluffy: in the UC w/ WebRTC, what terms should we use?
... we have
... 2 users trying to communicate
... 2 identity services trying to help them
... and a service trying to help them communicate
... most of the time, I see 1 user, 1 identifying provider

hhalpin: If you want to fit generic Client/Server on that
... you say is the user trying to communicate
... the endpoint of the peer to peer
... is the UA
... the other end point is the relying party
... where does the claim reside?
... what does the nmiddle party do?

fluffy: the middle party is not trusted, it's just a relay

hhalpin: i don't think there's a standard term for an untrusted middle man

[ Eve ? ]

hhalpin: within Client/Server, it's generally assumed there are tons of relying parties
... and few identity providers
... and they're shipped from the latter to the former
... I don't think there's a term for the middle term

[ Adjourn ]

RRSAgent: make minutes