Karl McGuinness mcguinness

A Layered Strategy for ID-JAG, WAG, and Cross-Domain Delegation

Executive Summary

Service providers increasingly need to authorize human users, services, and workloads across customer-controlled identity domains, and to distinguish a principal acting for itself from one acting on behalf of another, including multi-hop actor chains. The standards response should not be a separate end-to-end protocol for every combination of principal, issuer, delegation model, and topology. The recommended architecture:

Use OAuth Identity and Authorization Chaining Across Domains as the optional cross-domain choreography around the grant profiles.
Align the Identity Assertion JWT Authorization Grant (ID-JAG) and the Workload Authorization Grant (WAG) on the RFC 7523 redemption invariants they genuinely share; a common JWT Authorization Grant core is a candidate extraction from that demonstrated overlap, not a foundation designed up front.
Keep ID-JAG the human-subject profile for Cross-App Access (XAA), includ

Cross-Client Delegation for OAuth 2.0 Token Exchange

Draft response to ID-JAG issue #114 (Architectural Conflict in Gateway / Proxy Topology with Public Clients).

Bottom line. The choice comes down to the gateway's role in your topology. Default to the first; use the second when the gateway is genuinely a fan-out boundary; use the third only when neither is possible:

Recommended — gateway as client. Give the gateway its own user-audienced Identity Assertion, then run base ID-JAG from the gateway (a confidential client). Why the default: lowest mechanism, handles a public agent, needs no audience relaxation. Fits a gateway that reaches a manageable set of upstream services. Getting the gateway its own assertion has two realizations, with a real tradeoff (not just UX):
Silent (cross-client identity) — no prompt, and it carries identity directly from the agent's login;

Problem Statement

The OAuth 2.0 Authorization Framework defines the authorization_code grant type and refresh token. It doesn't establish any rules for issuing refresh tokens and explicitly states in Section 1.5 that "Issuing a refresh token is optional at the discretion of the authorization server". One of the explicit goals for Rfc6749 was to enable offline access to protected resources when the end-user is not present. It does not define any request semantics for how a client can explicitly request a refresh token or whether that refresh token's lifecycle should be bound to the user's session that granted the refresh token. Authorization Servers are free to define these behaviors on a per-implementation or policy basis.

OpenID Connect being the identity layer ontop of OAuth 2.0 needed to define some new authorization server behaviors to enable end-user consent for when a client can access their identity info

Keybase proof

I hereby claim:

I am mcguinness on github.
I am mcguinness (https://keybase.io/mcguinness) on keybase.
I have a public key whose fingerprint is DDF0 E3D1 7A4C 5192 A9D1 0BF7 4E27 92F7 5D23 D9F0

To claim this, I am signing this object:

Multiple SSH Keys settings for different github account

create different public key

create different ssh key according the article Mac Set-Up Git

$ ssh-keygen -t rsa -C "your_email@youremail.com"

	#!/usr/bin/env bash

	# Quinn Comendant <quinn@strangecode.com>
	# https://gist.github.com/quinncomendant/3be731567e529415d5ee
	# Since 25 Jan 2015
	# Version 1.1

	CMD=$1;

	if [[ `id -u` = 0 ]]; then