+1 (970) 616-4321contact@signet.id
     

    Accessing a URL delivers meta-content as well as the content itself. This model has proven superior with Open Graph, schema.org, the world’s API’s, and others. Why should identity data for objects and people be different?

    Distributed but Trusted

    Semantic identity stores the primary identity data about a resource through a combination of the data itself and attesting authorities that vouch for data’s validity. This allows an object to assert some information about itself and point to multiple trusted authorities for vetted data.

    This is useful principally in two situations:

    • Where the entity legitimately controls or maintains a lot of identity data about itself
    • Where a single source of authority cannot serve as the representation of the object because it is not the sole source of information

    simpleSSO is an example of limited specified semantic identity for a particular use case.

    Centralized Shortcomings

    Traditional identity architecture stores information about organizations, people, and other resources in centralized directories and ERP systems. This is not the natural relationship in every use case. Today, it’s most common to simply elide vetting by the appropriate authority by reassertion of data managed by a third party. There is no indication as to the source of ownership or degree of veracity. While expeditious, it’s not trustworthy.

    A federated identity provider generally also has to select an identity ecosystem — whether it’s a federation or a commercial implementation. This immediately restricts the set of services available to you.

    Semantic Identity

    The semantic web model, allowing sites to manage their own data for search engines, social media, and other resources, has proven to be the best solution for that use case. Extension of the successful semantic web model to distributed identity requires additional security and secrecy considerations.  To deal with private data, the set of identity data that is returned to a requester may be restricted and authentication of the requester is necessary.

    For example, a passport carries identifying information, but that information must be validated by checking with a central authority, and only an authorized agent can perform this check. Some of the identifying information may come from different authorities, such as visas.

    {
        "federal": {
            givenName: Suzie
            sn: Derkins
            issuance: timestamp
            expiration: timestamp
            authority: https: //authority.example.gov/identity/hashcheck?
        }
        "visas": {
            "china": {
                category: visitor
                expiration: timestamp
                authority: https: //authority.example.cn/passport/visacheck?
            }
            "switzerland": {
                category: visitor
                expiration: timestamp
                authority: https: //authority.example.ch/passport/visacheck?
            }
        }
    }
    

    Traditional identity architecture handles this scenario poorly as one authority is forced to reassert information on behalf of others or a collecting proxy is used. Semantic identity traces trace back to the relevant authority for the relevant data and ensures its authenticity by establishing trust in the queries.

    Principal Considerations

    The deployment environment and your functional objectives determine whether semantic identity would be suitable or a hindrance. Some of the major advantages and disadvantages can be described in sum, but to really explore whether semantic identity can enable new possibilities for you, please contact us.