71 Matching Annotations
  1. Dec 2020
  2. Mar 2020
    1. 10.2 Enterprise Knowledge Graphs

      Additional use case: business architecture.

  3. Nov 2019
    1. The second type of these “Imperative Shell” services execute side-effects outside of the bounded context, such as sending an email, SMS, or mobile push notification to a user, or calling out to some other external service.

      What if the bounded context is about managing side effects — say we are implementing a transactional mail service. Should we separate the “functional core” recording mail processing events from the “imperative shell” which performs the actual SMTP?

  4. Oct 2019
    1. Unfortunately, numerous widely-used tagless-final interfaces (like Sync, Async, LiftIO, Concurrent, Effect, and ConcurrentEffect) encourage you to code to an implementation.


    1. I have found that "publish subscribe" doesn't imply much more than indirect addressing of messages—if you compare any two messaging systems promising publish-subscribe, you find that they guarantee very different things, and most models are not useful in this domain.
    2. The log will become something of a commoditized interface, with many algorithms and implementations competing to provide the best guarantees and optimal performance.

      Are golang channels an implementation of log?

    3. ACID
    4. totally-ordered

      = an antisymmetric, transitive, and connex binary relation

    5. It is an append-only, totally-ordered sequence of records ordered by time.
  5. Sep 2019
    1. Independently on how the schema changes are handled, managing these changes is one of the most complex and error prone drawbacks associated with event sourcing. A strategy should be prepared upfront and considered on the system design.

      Plan for schema evolution upfront.

    2. Also your events will be based on a SomethingCreated or SomethingUpdated which has no business value at all. If the events are being designing like this then it is clear you’re not using DDD at all and you’re better of without event sourcing.

      litmus test

    3. CQRS is not an architectural pattern and should not be applied to a whole system.

      is an architectural pattern that should not be applied to a whole system

    4. The theory says that in distributed systems everything is eventually consistent but the pragmatic view of the real world says that we need to be real careful on what we choose to make eventually consistent.
    1. I think you don't hear much about using Kafka for event sourcing primarily because the event sourcing terminology doesn't seem to be very prevalent in the consumer web space where Kafka is most popular.
    1. Another way to get consistency is to assure serialized writes, i.e using the single-writer principle, meaning we make sure all writes concerning a particular entity ID occur on a single thread.

      This is the akka-cluster approach?

    2. One way to guarantee write consistency is by utilizing the event store’s optimistic concurrency control. A proper event store provides a way for the user to say “save this event only if the version of the entity is still x”.
    3. If the business logic fails we return an error to the client but if it succeeds a new event is emitted. In that case we must be able to save the new event to our event store with a guarantee that no other event has been stored for this particular entity ID in the meantime, or we would risk breaking the consistency of our domain objects.
    4. One alternative would be to have one topic per entity

      Other alternative: have a consumer group write a read model to a database, indexed by entity id.

  6. Jul 2019
    1. A resource owner may willingly delegate access to a resource by granting an access token to an attacker's malicious client.

      Looking for a good term for the business function that OAuth helps to implement: access delegation management?

    1. The components of identity assurance detailed in these guidelines are as follows: IAL refers to the identity proofing process. AAL refers to the authentication process. FAL refers to the strength of an assertion in a federated environment, used to communicate authentication and attribute information (if applicable) to a relying party (RP).

      Definition for identity assurance

    1. 8.3.2 Business Function A business function is a collection of business behavior based on a chosen set of criteria (typically required business resources and/or competencies), closely aligned to an organization, but not necessarily explicitly governed by the organization. Just like a business process, a business function also describes internal behavior performed by a business role. However, while a business process groups behavior based on a sequence or flow of activities that is needed to realize a product or service, a business function typically groups behavior based on required business resources, skills, competencies, knowledge, etc. There is a potential many-to-many relation between business processes and business functions. Complex processes in general involve activities that offer various functions. In this sense a business process forms a string of business functions. In general, a business function delivers added value from a business point of view. Organizational units or applications may coincide with business functions due to their specific grouping of business activities. A business function may be triggered by, or trigger, any other business behavior element (business event, business process, business function, or business interaction). A business function may access business objects. A business function may realize one or more business services and may be served by business, application, or technology services. A business role may be assigned to a business function. The name of a business function should clearly indicate a well-defined behavior. Examples are customer management, claims administration, member services, recycling, or payment processing. Figure 57: Business Function Notation


    1. Authentication (from Greek: αὐθεντικός authentikos, "real, genuine", from αὐθέντης authentes, "author") is the act of proving an assertion, such as the identity of a computer system user.

      The assertion does not need to be about an actor's identity per se?

    1. If you are looking for stateless authorization at your APIs, that is a valid use case. Our recommendation however is to rely on opaque OAuth 2.0 Access Tokens and convert them to JSON Web Tokens at your API Gateway, for example by using ORY Oathkeeper.

      So the authz server issues opaque tokens, and the gateway uses token introspection to derive JWTs?

  7. Jun 2019
    1. In requests to the authorization server, a client MAY indicate the protected resource (a.k.a. resource server, application, API, etc.) to which it is requesting access by including the following parameter in the request.

      With this design, the scope represents just the privileged operations.

      Alternative design: scope = {(priv_op_1, prot_res_1), ..., (priv_op_n, prot_res_n)}.

    2. protected resource (a.k.a. resource server, application, API, etc.)

      OAuth 2 does not distinguish between resource server and protected resource?

    1. But if we move completely into behavior land, then there’s definitely some kind of business action that brings the entity into existence. In our case this is place action. It’s a an integral verb of our domain and a part of the entity lifecycle, so we treat it accordingly — it belongs to the entity algebra.

      Still, why not offer the action from some BookingPlacementService?

    1. Access - Performing an action

      Performing a privileged operation (protected by access control) or an unprotected (?) operation (public access).

    2. Authorization decision - The result of evaluating applicable policy, returned by the PDP to the238 PEP. A function that evaluates to “Permit”, “Deny”, “Indeterminate” or “NotApplicable", and 239 (optionally) a set of obligations

      So authorization = evaluating applicable policy, returning a decision: permit | deny | indeterminate | not applicable.

      When mapping to OAuth 2.0, an authorization code (representing authorization grant) is optionally issued after authorization is decided, and an access token is used in access control.

    1. Once the End-User is authenticated, the Authorization Server MUST obtain an authorization decision before releasing information to the Relying Party. When permitted by the request parameters used, this MAY be done through an interactive dialogue with the End-User that makes it clear what is being consented to or by establishing consent via conditions for processing the request or other means (for example, via previous administrative consent).

      The spec talks about authorization by the end-user.

      May also want to think about this as “authorization by the system”, based on end-user consent (collected by GUI or by persistence).

    2. session cookies

      Session cookie as a means to do authentication?

      More logical to see session cookies as a means to re-use previous authentication?

    3. This enables an End-User who has multiple accounts at the Authorization Server to select amongst the multiple accounts that they might have current sessions for.

      So one browser state may have multiple sessions.

    4. display OPTIONAL. ASCII string value that specifies how the Authorization Server displays the authentication and consent user interface pages to the End-User. The defined values are:

      Why not iframe?

    5. The nonce parameter value needs to include per-session state and be unguessable to attackers.

      Should be unique to the authn attempt?

    6. ID Token

      Any use for id token within a single security domain?

    7. obtains End-User Consent/Authorization

      Split: obtains end-user consent (= permission mgmt) and performs authorization based on that.

    8. when the ID Token has a single audience value and that audience is different than the authorized party


    9. Client session

      Probably means “browser session maintained by the client”. At least not “authenticated session”. Note that in the session mgmt spec, the client Session typically starts after the id token is validated.

      We can generalize to consider it all being one session. In that case:

      1. RP initiates (or re-uses) a session.
      2. RP represents that session in nonce in an authn req.
      3. OP returns an id token containing the same nonce.
      4. RP validates the id token.
      5. RP updates the session with an “authenticated” event.
    10. exp REQUIRED. Expiration time on or after which the ID Token MUST NOT be accepted for processing.

      The session mgmt spec suggests that this may be used for session termination as well. Which means that the id token will possibly be processed repeatedly during the session.

    11. It MAY also contain identifiers for other audiences.


    12. The ID Token is a security token

      Several definitions of security token:

          A security token is a set of information that facilitates the sharing
         of identity and security information in heterogeneous environments or
         across security domains.  Examples of security tokens include JSON
         Web Tokens (JWTs) [JWT] and SAML 2.0 Assertions
         [OASIS.saml-core-2.0-os].  Security tokens are typically signed to
         achieve integrity and sometimes also encrypted to achieve
         confidentiality.  Security tokens are also sometimes described as
         Assertions, such as in [RFC7521].

      Both seem compatible. Then it becomes a physical or digital device (functional object) to transfer security information across security realms (e.g. physical and digital) or logical security domains. A token may be single-use (e.g. ID token) or multiple-use (e.g. physical OTP device).

    13. Claim Piece of information asserted about an Entity.

      Cf. Verifiable Credentials / RDF: a semantic triple.

    14. Authentication Context Class Reference

      Standardized by e.g. eIDAS: high/subst/low.

    15. Authentication Request OAuth 2.0 Authorization Request

      Potentially confusing. Notice this is a protocol message, not a domain object in the sense of “requesting authentication” within the bounded context of authentication management.

    16. Authentication Process used to achieve sufficient confidence in the binding between the Entity and the presented Identity.

      More precise: function that may be implemented using a process (such as challenge-response).

      Context: NIST Special Publication 800-63 Revision 3: Digital Identity Guidelines

      Talks about identity assurance management, composed of:

      • identity proofing management (enrollment)
      • authentication management
      • federation assurance management (communicating authentication and attribute information using assertions of a certain strength in a federated environment)

      OIDC is mostly about federation, relying on authentication.

    17. Authentication

      Typo: should be Authorization?

    18. authentication

      OIDC specifies authn in the sense of “using as a credential an ID token obtained from an OP”. Other ways of authn (as probably implemented by that OP) are out of scope.

    19. Authorization Server

      Potentially confusing name. The AS is the party in OAuth 2.0 that the client initiates interaction with, in order to obtain access tokens.

      Can be thought of as a set of endpoints that invoke authentication, consent, and authorization management functions.

    20. A web flow protocol for

      • authentication management (end-users and clients)
      • authorization management
      • consent management
      • access control
      • identity management (obtaining end-user info)
      • session management (correlating request with response)

      across logical security domains.

      Generally a useful source of knowledge / interoperable design concepts for these functions.

    1. Security policy domain, also known as security domain or realm: A scope over which a common security policy is defined and enforced by the security administrator of the security service.

      Any need to differentiate between security domain and security realm?

    1. An ID Token typically comes with an expiration date. The RP MAY rely on it to expire the RP session. However, it is entirely possible that the End-User might have logged out of the OP before the expiration date. Therefore, it is highly desirable to be able to find out the login status of the End-User at the OP.

      So here session mgmt is about syncing the RP session with the OP login state.

      The ID token represents the session state at the moment of issuing. The current spec extends the protocol to manage session state updates (e.g. logout).

    2. Session Continuous period of time during which an End-User accesses a Relying Party relying on the Authentication of the End-User performed by the OpenID Provider.

      A broader definition: continuous period of time during which a principal can perform privileged operations within a logical security domain, relying on authentication and authorization.

      See Page Notes: a session may also be not-yet-authenticated or not-authenticated-anymore.

    3. Note that any OP1 may be the RP2 to an OP2. In that case, any RP1 to OP1 will have

      session_state(RP1) == f(RP1, login_state(OP1))

      (by definition) where

      login_state(OP1) == session_state(RP2)

      (by design) and

      session_state(RP2) == g(RP2, login_state(OP2))

      (again, by definition).

      There does not seem to be a fundamental difference between session state and login state. Both session and login are event-sourced entities (with potentially various state representations). Differences are:

      1. convenient naming (i.e. are we talking about RP or OP)
      2. source of events (i.e. necessarily obtained from outside the own logical security domain, vs optionally / self-contained)

      These differences are relevant when agreeing to a protocol (i.e. OIDC web flow), but not so much when doing entity state management / persistence.

      So (outside of OIDC) we may generalize to have session mgmt encompass all state related to a set of authentication events. Looking at the spec, this set contains:

      • principal authenticated
      • principal authentication changed (e.g. higher assurance level)
      • principal logged out

      Optionally, systems may support having multiple authenticated principals.

    4. Provides some generally useful concepts for session mgmt. While the emphasis is on enabling OIDC web flow, it is written from experience in web app security.

      Enables the RP to delegate session mgmt to the OP. This will keep session state – an RP-specific representation of the OP login state, containing the OP browser state (i.e. who are the end-users and (how) are they authenticated in the current browser).

    5. The id_token_hint parameter to a logout request can be used to determine which RP initiated the logout request. Logout requests without a valid id_token_hint value are a potential means of denial of service; therefore, OPs may want to require explicit user confirmation before acting upon them.

      This is authentication of the RP?

    6. Opaque value used by the RP to maintain state between the logout request and the callback to the endpoint

      Seems to be generic state – not necessarily security related

    7. If a cookie is used to maintain the OP browser state, the HttpOnly flag likely can't be set for this cookie because it needs to be accessed from JavaScript. Therefore, information that can be used for identifying the user should not be put into the cookie, as it could be read by unrelated JavaScript.


    8. The authentication status of Clients being used by the End-User changes.


    9. The set of users authenticated to the browser changes (login, logout, session add).

      So multiple end-users can have be logged in within a login state.

    10. The OP browser state is typically going to be stored in a cookie or HTML5 local storage. It is origin bound to the Authorization Server. It captures meaningful events such as logins, logouts, change of user, change of authentication status for Clients being used by the End-User, etc. Thus, the OP SHOULD update the value of the browser state in response to such meaningful events.

      Event-sourced entity that could be called session as well.

    11. Browser state

      Definition below. Relation to login state?

    12. OP browser state


    13. The generation of suitable Session State values is specified in Section 4.2 (OP iframe), and is based on a salted cryptographic hash of Client ID, origin URL, and OP browser state.

      So a session state represents the OP login state contains the OP browser state.

    14. the End-User's login state at the OP

      Distinguish between session (@ RP) and login state (@ OP)?

    15. session management

      Seems to be used here as: managing the RP session (since we’re not talking about an OP session).

    16. In OpenID Connect, the session at the RP typically starts when the RP validates the End-User's ID Token.

      But a “semi-session” starts already at the authentication request. (Unauthenticated session / initializing session.)

  8. Mar 2019
    1. The value of the "grant_type" is "urn:ietf:params:oauth:grant- type:jwt-bearer".

      Is this spec also useful for the grant_type=code case?