Re: Authentication vs Authorization clarification

I guess that makes sense, so what I call business level authorization is
basically identification?

I think identification is what we're working on with DID and Verifiable
Claims. DID-Auth for the authentication then.

Authorization is probably mostly out of scope for truly decentralized
services. There will still be a need for semi-centralized services that we
need to help interact with the decentralized world in these early days
still, I'm a big fan of OCAP. But essentially we can just use whatever is
best practice currently including OAuth.

Pelle




On Tue, Mar 27, 2018 at 11:25 AM, Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> On 27 March 2018 at 19:17, Pelle Braendgaard <pelle.braendgaard@consensys.
> net> wrote:
>
>> Hi,
>> I just wanted to clarify my statement in the call, as I think it caused
>> some confusion.
>>
>> In a HTTP based world, there is a very clear separation that is needed
>> for a very good reason.
>>
>> Blockchains are very different as there is no central server that we need
>> to authorize ourselves with.
>>
>> Interacting with apps on all the different blockchains is very much out
>> of scope I believe, so in most cases traditional protocol level
>> Authorization is not needed.
>>
>> That said and (this is where I think the confusion arrived). People are
>> and will be using verified credentials for authorization on a businesses
>> (NOT protocol level). So the nice clean separation we had in the HTTP world
>> is maybe not as clean anymore.
>>
>> I don't think we need to model authorization at all for DID-AUTH, but
>> just like authorization is built on top of traditional authorization
>> method, we should just be aware that business level authorizations will be
>> built on top of it. Which is why Marcus 2.) definition is what we are
>> currently supporting with uPort.
>>
>
> I think the bigger challenge in standards is not separating authentication
> (authn) and authorization (authz)
>
> But rather, separating identification and authentication.
>
> The only standard to date that I have found to really do this cleanly is
> WebID [1]
>
> There are separate specs for identity, for authn, for authz
>
> I know of no other system that comes even close to this clean level of
> modularity -- the mixing normally starts quite early -- and decoupling
> becomes impractical, leading to balkanization of systems.
>
> [1] https://www.w3.org/2005/Incubator/webid/spec/
>
>
>>
>> Pelle
>>
>>
>> --
>> *Pelle Brændgaard // uPort Engineering Lead*
>> pelle.braendgaard@consensys.net
>> 49 Bogart St, Suite 22, Brooklyn NY 11206
>> <https://maps.google.com/?q=49+Bogart+St,+Suite+22,+Brooklyn+NY+11206&entry=gmail&source=g>
>> Web <https://consensys.net/> | Twitter <https://twitter.com/ConsenSys> |
>> Facebook <https://www.facebook.com/consensussystems> | Linkedin
>> <https://www.linkedin.com/company/consensus-systems-consensys-> |
>> Newsletter
>> <http://consensys.us11.list-manage.com/subscribe?u=947c9b18fc27e0b00fc2ad055&id=257df01285&utm_content=buffer1ce12&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer>
>>
>
>


-- 
*Pelle Brændgaard // uPort Engineering Lead*
pelle.braendgaard@consensys.net
49 Bogart St, Suite 22, Brooklyn NY 11206
Web <https://consensys.net/> | Twitter <https://twitter.com/ConsenSys> |
Facebook <https://www.facebook.com/consensussystems> | Linkedin
<https://www.linkedin.com/company/consensus-systems-consensys-> | Newsletter
<http://consensys.us11.list-manage.com/subscribe?u=947c9b18fc27e0b00fc2ad055&id=257df01285&utm_content=buffer1ce12&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer>