Re: [apps-discuss] What auth server supplies email addresses? Was webfinger discussion

[Alessandro Vesely <[e-mail]>]

Hi Blaine,

On 02/Apr/12 11:52, Blaine Cook wrote:
> 
> Basically, the breakdown is this:
> 
> Discovery:
> 
> a. email (and URI, but ignore that) based: webfinger / swd
> b. for auth protocols: the proposed oauth discovery draft, the
> mechanism that browserid uses, openid 2.0's current discovery
> 
> Anonymous Claims:
> 
> I gather that the google folks and others have figured out a way to do
> the anonymous-claims (I don't know the formal cryptoterm for that)
> with OAuth, but here's my take with browserID in a nutshell:
> 
> The current BrowserID spec has a javascript API like:
> 
> navigator.id.get( [email], callback )
> 
> which will produce a JWT assertion, signed by domain(email) (or a
> trusted 3rd party), that proves that the bearer owns the email
> address.
> 
> This can be generalised, of course, to be something (theoretical) like this:

So by "(theoretical)" you mean it may be eventually specified/
implemented but currently nothing like that exist, correct?

> navigator.claim.get( claimType, [desired claim-value-or-something], callback )
> 
> for example,
> 
> navigator.claim.get( licensedToDrive, 'fr', function (claim) {
> console.log(claim) } )
>
> which would provide a JWT signed by some-random-authority that asserts
> whether or not the person sitting at the browser is allowed to drive
> in France. The client would then verify that the assertion was signed
> by the stated issuer AND that the client TRUSTS the issuer (e.g., if
> the assertion is signed by gov.uk, then most companies in the UK would
> trust the assertion, but many in the United States (or Iran) would
> not).
> 
> Does that make sense?

For that to work, the claim provider either has to be obtained from a
standardized list of claims, or can be passed as an argument by the
caller, who may get it from the user.  For example, assuming that any
EU country can issue driving licenses valid in France, you'd need the
user to tell where she got her license from.

My [e-mail] example is similar.  Or it could have a shorter
generalization, like navigator.id.get( "@example.com", myCallback );
where the user interacts with the server to specify what kind of
address alias (opaque, official role, name+folder@, name.surname@,
etc.) she wants to be returned to the RP, assuming her server supports
such capabilities.

Would shops use any of those?

> On 1 April 2012 18:40, Paul E. Jones <[e-mail]> wrote:
>> I don't know.. I wasn't there.
>>
>> Blaine?
>>
>> Paul
>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]]
>>> On Behalf Of Alessandro Vesely
>>> Sent: Sunday, April 01, 2012 6:28 AM
>>> To: [e-mail]
>>> Subject: Re: [apps-discuss] What auth server supplies email addresses? Was
>>> webfinger discussion
>>>
>>> On 30/Mar/12 20:03, Paul E. Jones wrote:
>>> > What you describe sounds a bit like JWT:
>>> > http://openid.net/specs/draft-jones-json-web-token-07.html
>>> >
>>> > Or, it might be OpenID Connect, which uses JWT.  (What you describe is
>>> > not in OpenID 2.0.)
>>>
>>> Aha, thanks.  So JWT is how the claim is (supposed to be) transferred to
>>> the RP, correct?  I'm trying to make sense of a presentation of anonymous
>>> claims that Blaine Cook gave on last Thursday (with the drive-in-France
>>> example).  Is it not specified or implemented, yet?
>>>
>>> >> -----Original Message-----
>>> >> From: Alessandro Vesely [mailto:[e-mail]]
>>> >>
>>> >> I may be conflating webfinger, openid, browserid, webid, and some
>>> >> other protocols of that sort.  At any rate, it was said that a
>>> >> functionality relevant to some of those is to certify a generic
>>> >> claim, for example whether someone is legally allowed to drive a
>>> >> lorry in France.  The user would indicate the kind-of-claim (driving
>>> >> license) and a trusted certifier (the French motoring authority)
>>> >> without revealing his/her identity.  The relaying party would then
>>> >> let the user login at the certifier's site in order to eventually
>>> >> obtain the certificate.
>>> >>
>>> >> By the same logic, given that example.com should be universally
>>> >> trusted for email addresses that end with "@example.com", its server
>>> >> would be able to provide a certified, anonymous email address
>>> >> ([e-mail]) to a shop, on behalf of a customer who wishes to
>>> >> protect his/her main address.
>>> _______________________________________________
>>> apps-discuss mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>