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

[Chasen, Les]

Sorry .. I got sidetracked on other stuff and am just getting back to some old emails.  Is this still an open question/issue?  I don't think I saw a solution.

So if I am understanding, you have @example*dept and you want =you and =me to have permission to maintain @example*dept.  Is that close?  If so that sounds to me like an 'authorization' use case.  IN other words, is =you, =me or =whomever allowed to view a particular resource.  I tackle that particular issue through the use of an authorization sep.  The RP would first do normal authentication which proves the user is the identifier and then locates the authorization SEP to check to see if he has permissions to access the particular resource.  The authorization SEP could point to something like @example*dept/+authorize.  




contact: =les
sip: =les/(+phone)
chat: =les/skype/chat
 
 

> -----Original Message-----
> From: Michael Mell [mailto:mike at nthwave.net]
> Sent: Thursday, May 17, 2007 11:41 AM
> To: Chasen, Les
> Cc: markus.sabadello at gmail.com; dev at inames.net
> Subject: Re: [Dev] Acting As If =you were @example*dept
> 
> 
> On May 16, 2007, at 5:09 PM, Chasen, Les wrote:
> 
> > Or put a ref in @example*dept to =you.  If there is no authentication
> > sep in @example*dept then the resolver should find the authentication
> > sep for =you.  Then if I am not mistaken the op should pull the cid
> > for =you and request appropriate password.
> 
> Hi Les,
> I have two problems with that approach:
> 1) When using a ref, the XRDS and canonical id of the Referred (e.g.
> =you) Iname is returned from resolution. So with a ref on @example*data
> to =you, resolving @example*data would return the XRDS for =you. That's
> not the desired behavior.
> 
> 2) =you AND =me must both have rights as @example*dept. A ref to =you
> cuts out =me.
> 
> 
> On May 16, 2007, at 5:02 PM, Markus Sabadello wrote:
> 
> > I think it would probably work, but I don't envy anyone trying to
> > implement an OP that supports it. There will be a lot of redirecting
> > to get right.
> 
> Ok, I'll worry about that part. Though I don't see this as complicated
> at all.
> 
> > A simpler solution might be OpenID Delegation, but with that you would
> > have to give the @example*dept password to =me and =you.
> 
> That's not acceptable in this use case. The password must remain
> private with the registrant of @example*dept to maintain OP account
> control.
> 
> 
> Thanks
> Mike
> 
> 
> 
> >  On 5/17/07, Michael Mell <mike at nthwave.net> wrote:
> >
> >          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
> >
> >          _______________________________________________
> >          Dev mailing list
> >          Dev at inames.net
> >          http://dev.inames.net/mailman/listinfo/dev
> > <http://dev.inames.net/mailman/listinfo/dev>
> >
> >
> >
> >