No subject

an OP and an IdP are not significant.

- John
> 
> -- Dick
> 
> [1] http://www.oasis-open.org/committees/download.php/11886/saml- 
> glossary-2.0-os.pdf
> 
> On 30-Oct-06, at 10:27 PM, Recordon, David wrote:
> 
>> I'll let Dick explain since it was his proposal and I didn't really  
>> care about if we changed the name or not. ;)
>>
>> --David
>>
>> From: Patrick Harding [mailto:pharding at pingidentity.com]
>> Sent: Monday, October 30, 2006 7:47 PM
>> To: Recordon, David; specs at openid.net
>> Subject: RE: "Editors" Conference Call
>>
>> Dave,
>> Can you please clarify how an OpenID Provider is 'very' different  
>> from the role of Identity Provider as defined in SAML or WS-*.
>> Thanks
>> - Patrick
>>
>>> Rename "Identity Provider" to "OpenID Provider" (IdP -> OP) to add
>> clarity to the term since IdP has a very different meaning in the SAML
>> and WS-* worlds
>>
>>
>>
>>
>> -----Original Message-----
>> From: specs-bounces at openid.net on behalf of Recordon, David
>> Sent: Mon 10/30/2006 7:51 PM
>> To: specs at openid.net
>> Subject: "Editors" Conference Call
>>
>> This morning Dick, Josh, and I got on Skype for 2.5 hours to try and
>> hash through all the remaining proposals.  Unfortunately Brad couldn't
>> join us, though I did talk to him about some of this stuff as well
>> beforehand.
>>
>>  - Authentication Age will be developed as an extension due to  
>> questions
>> around what is the best way for it to work, what features does it  
>> need,
>> etc
>>
>>  - The field "setup_url" will be removed from a checkid_immediate
>> response, rather the RP should fallback to a checkid_setup request to
>> complete the transaction.  It has been found that in the, albeit few,
>> implementations of checkid_immediate this is the behavior for the
>> setup_url anyway.
>>
>>  - Support bare requests by having the field "openid.return_to" as
>> optional in checkid_* requests.  There is a worry of user's not  
>> knowing
>> when they'll be redirected back and when they won't, though that will
>> only be worked out by allowing this functionality.
>>
>>  - Clarify that the openid.realm parameter should be used to uniquely
>> identifier relying parties
>>
>>  - There are some places where it could be clear in step-by-step
>> instructions of what an IdP needs to do in various parts of the
>> protocol, like is done in section 12 for rp's.  Sxip will provide
>> pointers to where this clarity can be added.
>>
>>  - Rename "Identity Provider" to "OpenID Provider" (IdP -> OP) to add
>> clarity to the term since IdP has a very different meaning in the SAML
>> and WS-* worlds
>>
>>  - The spec won't speak to what a RP should do if it has an identifier
>> like "user at example.com", worried about setting a confusing  
>> precedent of
>> allowing this form of identifier for discovery.  Users are used to
>> entering, "example.com" in their URL bar to goto the site, so entering
>> the same to login doesn't seem like to far of a stretch.  All of  
>> OpenID
>> has a user education challenge and this doesn't seem very different.
>>
>>  - Spec will say in essence, "RP's SHOULD give the text field a user
>> enters their OpenID Identifier a name attribute with a value of
>> 'openid_identifier', though if a RP wishes to support rich clients it
>> MUST do so".
>>
>>  - Dick will be writing a separate document discussing how RPs can
>> advertise services, logos, etc
>>
>>  - There cannot be parameters with the same name, make sure spec says
>> this, we think it does.
>>
>>  - Josh will be updating his delegation proposal patch to specify two
>> identifiers for all transactions.  This will create a consistent
>> paradigm when dealing with delegation or when not.
>>
>> Goal is to have all of these changes made by end of day Wednesday.  I
>> doubt I've added enough detail in all places, so feel free to ask for
>> clarifications or wait to comment on the next draft.
>>
>> --David
>> _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>>
> 
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs