Re: [DG-IDPro] BoK: Authorization taxonomy

31 Jan 2017

      thx Stu,

I have added the matrix as I have understood it (which may be totally
wrong). What exactly was thought to be 'lifecycle'?

Thorsten

On 30.01.2017 23:44, Stu Lincoln wrote:
...
I see the document is now in place and have started a data dump under
management. I will finish off by 12pm EST Tuesday. So we can all
review the complete document and matrix.
Thanks
Stu
On Fri, Jan 27, 2017 at 7:21 PM Andrew Hughes
mailto:andrewhughes3000@gmail.com> wrote:
Hi Janelle - not to worry, this conversation will be going on for
    a long time :)
We've got a segment called 'Management' - that might be the spot
    for audit
*Andrew Hughes *CISM CISSP 
    Independent Consultant
    *In Turn Information Management Consulting*
o  +1 650.209.7542 tel:%28650%29%20209-7542
    m +1 250.888.9474 tel:%28250%29%20888-9474
    1249 Palmer Road,
    Victoria, BC V8P 2H8
    AndrewHughes3000@gmail.com mailto:AndrewHughes3000@gmail.com 
    ca.linkedin.com/pub/andrew-hughes/a/58/682/
    http://ca.linkedin.com/pub/andrew-hughes/a/58/682/
    *Identity Management | IT Governance | Information Security *
On Fri, Jan 27, 2017 at 6:45 AM, Janelle Allen
    mailto:janelle@sharpshootn.com> wrote:
Hi Andrew,
I’m apologize for being so late to this conversation and this
        perhaps has been discussed but another item to consider adding
        to the BOK might be Auditing.  I know this itself is not
        really an identity subject so it may reside outside of the
        scope of the BOK but does seem to go hand in hand in hand; the
        familiar AAA services.  I can very much also understand any
        argument that it may not belong at all to the BOK at all but
        it might be worth considering if it has not been considered
        thus far.  Where should it belong a major heading unto
        itself?  A best practice?
Kind Regards,
Janelle Allen
...
On Jan 27, 2017, at 2:22 AM, Thorsten H. Niebuhr [WedaCon
        GmbH] mailto:tniebuhr@wedacon.net> wrote:
Re the 'real-life' scenarios and 'practices'
Would it be beneficial to use a common, general structure for
        each Area (Identity, Management,Authentication,
        Authorization)?, eg something like
* Identities
              o Standards and Concepts
              o Regulations
              o Best-Practice
              o Protocols
          * Management
              o Standards and Concepts
              o Regulations
              o Best-Practice
              o Protocols
          * Authentication
              o Standards and Concepts
              o Regulations
              o Best-Practice
              o Protocols
          * Authorization
              o Standards and Concepts
              o Regulations
              o Best-Practice
              o Protocols
Given the current discussion, that would allow a sorting like
        below
* Authorization
              o Standards and Concepts
                  + Authorization Models
                      # xBAC
                     #
+ Assertions
                  + Trust Elevation
                  + Assurance Levels
              o Regulations
                  + EU-GDPR (related Articles)
                  + EU- ePrivacy Regulation
                 +
o Best-Practice
                  + Centralized vs Decentralized
                  + Policies
                 +
+
o Protocols
                  + UMA
                  + OAuth
                 +
I first placed 'Protocols' in the 'Technology' Ring, but I
        think it make sense to use the same idea here as we have for
        the other layers (Operations,
        Implementation/Align-Plan-Organize). That would allow us to
        simple 'short-describe' the protocols and let the
        'TechnologyRing' serve as a placeholder.
T.
On 23.01.2017 20:31, Ken Dagg wrote:
...
The could be one Sub heading in the Implementation
        Sub-section for each implementation. Subsections in each
        implementation could be a description of the implementation
        and lessons learned (positive and negative) from the
        implementation. I believe that this type of information
        would be valuable for IdPros to know because it provides
        real life examples of what has and has not worked.
Ken
On Mon, Jan 23, 2017 at 2:01 PM Andrew Hughes
        mailto:andrewhughes3000@gmail.com> wrote:
Hmmm... I'm not sure I follow on the 'implementations'
            idea...
Could you give some example sub-headings?
What kinds of practices should ID Pros know about? What
            facts/knowledge should they have?
andrew.
*Andrew Hughes *CISM CISSP 
            Independent Consultant
            *In Turn Information Management Consulting*
o  +1 650.209.7542 tel:%28650%29%20209-7542
            m +1 250.888.9474 tel:%28250%29%20888-9474
1249 Palmer Road,
            Victoria, BC V8P 2H8
            AndrewHughes3000@gmail.com
            mailto:AndrewHughes3000@gmail.com 
            ca.linkedin.com/pub/andrew-hughes/a/58/682/
            http://ca.linkedin.com/pub/andrew-hughes/a/58/682/
            *Identity Management | IT Governance | Information
            Security *
On Mon, Jan 23, 2017 at 10:58 AM, Ken Dagg
            mailto:kendaggtbs@gmail.com> wrote:
Andrew,
Great work!
Suggestions:
                - Would the Considerations section be better as a
                sub section under Authorization Models. I believe
                that each model should have considerations.
                - Should there be an Implementations sub-section
                that identifies where Authorization models have been
                implemented. This could include lessons learned.
Ken
On Mon, Jan 23, 2017 at 11:58 AM Andrew Hughes
                mailto:andrewhughes3000@gmail.com> wrote:
Hi folks, here's my imperfect taxonomy for
                    'areas related to authorization and access
                    control that an ID Pro should know about'.
Please help to put the items in the right spots
                    and correct errors!
* Authorization
                     *
                          o Authorization policy evaluation
                         o
                              + Proofs of assertion (tokens,
                                tickets, cookies, cryptographic methods)
                             +
                                  # Bearer methods v proof of
                                    possession methods
                              + Access control policy, authorization
                                policy, 
                              + Static evaluation, dynamic evaluation
                              + Is there an ‘authorization equation’
                                for policy evaluation?
                             +
                                  # e.g. Given an identified entity
                                    and a requested resource, select
                                    the
                                    correctly-scoped authorization
                                    policy, evaluate the policy,
                                    grant || deny || require
                                    trust elevation for the resource
                                    access, log the events
                          o Relationship to Identification,
                            Authentication, Access Control
                         o
                              + The characteristics of each 
                              + The 'cross-over' aspects of each
                                (e.g. OAuth-style authentication via
                                proof of resource access - is this
                                related to an ‘authorization
                                equation’ approach?)
                          o Authorization models, processes, protocols
                         o
                              + SAML, OAuth, UMA
                              + Directories, decentralized models 
                              + Access control models
                             +
                                  # RBAC
                                  # ABAC
                              + Trust Elevation (e.g.
                                re-authentication, step-up
                                authentication, claims gathering)
                          o Considerations for choosing specific
                            models, protocols
                         o
                              + Risk
                              + Authorization model matching to
                                credential characteristics,
                                identification method, available
                                authenticators
                              + Centralized v decentralized
                              + Degree of independence of
                                authorization policy decision v
                                access control decision
*Andrew Hughes *CISM CISSP 
                    Independent Consultant
                    *In Turn Information Management Consulting*
o  +1 650.209.7542 tel:%28650%29%20209-7542
                    m +1 250.888.9474 tel:%28250%29%20888-9474
                    1249 Palmer Road,
                    Victoria, BC V8P 2H8
                    AndrewHughes3000@gmail.com
                    mailto:AndrewHughes3000@gmail.com 
                    ca.linkedin.com/pub/andrew-hughes/a/58/682/
                    http://ca.linkedin.com/pub/andrew-hughes/a/58/682/
                    *Identity Management | IT Governance |
                    Information Security *
_______________________________________________
DG-IDPro mailing list
DG-IDPro@kantarainitiative.org
                    mailto:DG-IDPro@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/dg-idpro
-- 
                Kenneth Dagg
Independent Consultant
Identification and Authentication
613-825-2091 tel:%28613%29%20825-2091
kendaggtbs@gmail.com mailto:kendaggtbs@gmail.com
-- 
        Kenneth Dagg Independent Consultant Identification and
        Authentication 613-825-2091 tel:%28613%29%20825-2091
        kendaggtbs@gmail.com mailto:kendaggtbs@gmail.com
_______________________________________________
        DG-IDPro mailing list
        DG-IDPro@kantarainitiative.org
        mailto:DG-IDPro@kantarainitiative.org
        http://kantarainitiative.org/mailman/listinfo/dg-idpro
_______________________________________________
        DG-IDPro mailing list
        DG-IDPro@kantarainitiative.org
        mailto:DG-IDPro@kantarainitiative.org
        http://kantarainitiative.org/mailman/listinfo/dg-idpro
_______________________________________________
    DG-IDPro mailing list
    DG-IDPro@kantarainitiative.org mailto:DG-IDPro@kantarainitiative.org
    http://kantarainitiative.org/mailman/listinfo/dg-idpro
_______________________________________________
DG-IDPro mailing list
DG-IDPro@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/dg-idpro

Re: [DG-IDPro] BoK: Authorization taxonomy

Thorsten H. Niebuhr [WedaCon GmbH]