[Openid-specs-ab] Identifiers

[John Bradley]

The verification rules for the connect approach of checking that the host part of the identifier matches the issuer are quite simple.

If we support arbitrary URI as claimed identifiers we need to have a verification process for them like openID 2.0 has via discovery.

The argument given to me is that openID discovery is too hard so we should consider that, though I don't necessarily think that is the case.

The thing is that in openID 2.0 the identifier is a discovery document and in connect it is a protected resource,  though they could be the same thing in future.

John B.
On 2010-12-28, at 2:23 PM, Mike Jones wrote:

> What if the protected resource is an identifier like xri://=!4138.AF19.8976.CD2A or other kinds of resources without a host component (some of which may not have been invented yet)?  We'll have a far more general solution if both identifiers are identified by URIs, even if the discovery identifier and the claimed identifier are distinct.
> 
> 				-- Mike
> 
> -----Original Message-----
> From: John Bradley [mailto:ve7jtb at ve7jtb.com] 
> Sent: Tuesday, December 28, 2010 8:44 AM
> To: Mike Jones
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Identifiers
> 
> I think the Connect proposal separates the discovery identifier from the protected resource identifier/claimed ID.
> 
> So while I might enter jbradley at facebook.com for discovery.   The actual identifier returned by the protocol would be:
> 
> ID '12874sdfjlsdf" 
> IDP "facebook.com"
> 
> Originally David proposed that they be combined in the assertion in the email style form.  
> 
> The argument against that was that they are not necessarily acct: URI 
> 
> If the combined form was an acct: URI that might argue for using that form.
> 
> If the identifier is a acct: URI (leaving aside the creation of a new URI scheme issue) can an identifier also be a https: URL or other type?
> 
> I think some people would prefer to restrict it to only the one form of identifier.
> 
> John B.
> On 2010-12-27, at 4:57 PM, Mike Jones wrote:
> 
>> Shouldn't the canonical form of identifiers using e-mail address syntax be either a mailto: or acct: URI?
>> 
>> 				-- Mike
>> 
>> -----Original Message-----
>> From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of John Bradley
>> Sent: Monday, December 27, 2010 6:16 AM
>> To: openid-specs-ab at lists.openid.net
>> Subject: [Openid-specs-ab] Identifiers
>> 
>> We have had several discussions about the new connect type identifier format proposed by David being more SAML like (His idea).
>> 
>> This would break it into two parts.
>> 1:  IdP identifier  (Issuer/EntityID)
>> 2: LocalID   (Subject)
>> 
>> The question was around if they should be formatted  LocalID at IdP or as two elements to save parsing.
>> 
>> One question is when you have a attribute provider (3rd party protected resource) and it returns a JWT for the Subject based on a IdP supplied access token.
>> 
>> We need to specify the Issuer of the JWT separately from the Issuer of the original Identity assertion.
>> 
>> If we are going to allow 3rd parties to make assertions about subjects having a fully qualified name format may be a useful thing.
>> 
>> I don't think in our discussion at FaceBook we had a good reason to keep a fully qualified name format.
>> 
>> I am now leaning in favour of the localID at IdP format being included in all assertions and the older URL format being included for backwards compatibility.
>> 
>> Are there any opinions about having something like a optional "name Identifier format" element so we could say explicitly if the identifier is PPID or something else?
>> 
>> Hope everyone had a good Christmas.
>> 
>> We need to get rolling with this in the New Year.
>> 
>> John B.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20101228/081e2c12/attachment.p7s>