[Dev] Acting As If =you were @example*dept

Michael Mell mike at nthwave.net
Thu May 17 11:56:56 EDT 2007


On May 17, 2007, at 8:37 AM, Owen Davis wrote:

> On May 16, 2007, at 7:38 PM, Gabe Wachob wrote:
>
>> I'm not sure this is an inames- specific question, right?

Right. The example could have used a mixture of identifier types.

> That's partly what we're trying to answer here.  We have the use case 
> Mike described below and there are variations on it as well.  For 
> instance; @names (like domain names) may frequently belong to 
> organizations and have multiple people who have the need to administer 
> the @name.  There may be different roles associated with the different 
> users.  What's the best way to manage and maintain these roles with 
> inames and openid?

Note that the RP in the use case below is a Legacy System which is only 
capable of being configured to authorize a single identifier. Role 
based permissions on individual identifiers are greatly preferred but 
not always possible. I don't have any question about how to implement 
roles.


Mike

>>> -----Original Message-----
>>> From: dev-bounces at inames.net [mailto:dev-bounces at inames.net] On 
>>> Behalf Of
>>> Michael Mell
>>> Sent: Wednesday, May 16, 2007 4:33 PM
>>> To: dev at inames.net
>>> Subject: [Dev] Acting As If =you were @example*dept
>>>
>>> An ibroker Customer has registered @example. Customer has a Legacy
>>> system which can only be configured to grant access to a single
>>> identifier, in this case, @example*dept. Customer wants =you and =me
>>> to authenticate using OpenID 1.1 to this system /as/ @example*dept
>>> without giving the @example*dept password to either =you or =me.
>>>
>>> I see a very simple way to implement this: The OP will enable
>>> @example*dept to create and manage a list of inames that are
>>> permitted to Act As @example*dept. The registrant enters =you and =me
>>> to this mapping. After creating the mapping, =you will enter
>>> "@example*dept" at the OpenID login box at the Legacy RP. The browser
>>> will be redirected to the OP for @example*dept. The OP will recognize
>>> that @example*dept has Acting As mappings so, in addition to the
>>> usual password field, the OP will present an iname form field to
>>> allow =you or =me to authenticate to the OP as =you or =me. After
>>> verifying the =you or =me password, the OP will redirect the browser
>>> back to the Legacy RP with the appropriate @example*dept tokens to
>>> confirm authentication as @example*dept.
>>>
>>> The OP will not accept Acting As authentications to manage the
>>> account -- =you may not Act As @example*dept at the OP.
>>>
>>> This method could be extended a step further so that the mapping list
>>> is irrelevant and any OP account can Act As a configured account such
>>> as @anonymous. Clearly the @anonymous registrant and Acting As users
>>> would need to be educated about the effects of this authentication.
>>>
>>> As I understand the term, this is a form of directed identity. Do
>>> people see this as a valuable feature in an OP?
>>>
>>> Thanks,
>>> Mike
>
>



More information about the Dev mailing list