Re: Authentication vs Authorization clarification

Melvin: that’s exactly the correct distinction. The distinction between
authentication and authorization is a false comparison.

Authorization depends on identification (often by asserting an identifier)

If the relying party wishes to gain confidence in the identifier (not
tampered, not forged, subject is the intended subject) then an
authentication process is performed.

This is why DID-Auth is sometimes described as verification of the DID
Object, rather than a ‘login’ activity.

Weirdly, the full process of logging into a web site is actually mostly an
authorization activity ;-) the user authenticates their user ID which is
accepted by the server.
On Tue, Mar 27, 2018 at 1:35 PM Pelle Braendgaard <
pelle.braendgaard@consensys.net> wrote:

> 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
> <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>
>
-- 

*Andrew Hughes *CISM CISSP
Independent Consultant
*In Turn Information Management Consulting*

o  +1 650.209.7542
m +1 250.888.9474
1249 Palmer Road,
Victoria, BC V8P 2H8
AndrewHughes3000@gmail.com
ca.linkedin.com/pub/andrew-hughes/a/58/682/
*Identity Management | IT Governance | Information Security *