Để đi đến định nghĩa GSA được tích hợp trong 3 loại dựa vào các kiểu SA [20] . Kiến trúc này được lựa chọn bởi các tác giả sáng tạo ra GSA trong môi trường Multicast bằng cách tham chiếu đến chuẩn IETF (Internet Engineering Task Force ) (Framework [19]). Cần phải có sự sửa đổi giữa một KD và một nhóm (cho người gửi, người nhận hoặc cả hai) và giữa các thành viên. Trong khi tham chiếu Framework, KD được mang kèm các điều khiển truy nhập tới khóa nhóm, với chính sách phân phối tới các thành viên client hoặc cho các thành viên tương lai và với sự phổ biến khóa nhóm tới thành viên gửi và nhận. Kiến trúc này áp dụng chung trong rất nhiều môi trường quản lý khóa nhóm ([1, 54, 26, 25]).
Có hai SA được thiết lập giữa KD và các thành viên. Thứ nhất tham chiếu đến Category 1 SA (hay còn gọi SA1), thứ hai là Category 2 SA (hay SA2). Thêm vào đó sẽ có SA thứ 3 được thiết lập giữa các thành viên gửi và nhận còn gọi Category 3 SA (hay SA3). Ba SA được thể hiện trong hình dưới đây
Hình 2.3: Định nghĩa GSA.
Các khái niệm SA1, SA2 và SA3 được sử dụng đơn giản theo phần đưa ra sau (khái niệm pull/registration SA, push/rekey SA, và data security SA đã được sử dụng)
SA1 được khởi tạo bởi một thành viên để ―pull‖ thông tin GSA từ KD. Để làm được điều này thành viên gửi yêu cầu tham gia thành viên nhóm an toàn, hoặc có các khóa GSA được khởi tạo sau khi mất kết nối từ nhóm (chẳng hạn khi máy tính bị tắt trong khi thao tac đổi khóa). Thông tin GSA sẽ được ―pulled‖ xuống từ các KD, bao gồm: SA, Keys và các chính sách được sử dụng để đảm bảo cho việc truyền dữ liệu giữa thành viên gửi và nhận (đây chính là SA3 )
Lưu ý rằng SA3 là một danh sách các SA, có thể bao gồm nhiều SA được thiết lập giữa thành viên gửi và nhận cuối cùng. Có thể tồn tại chẳng hạn một SA của Category 3 trong đó tất cả người gửi chia sẻ chung 1 khóa và kết nối với thông tin cần gửi.
Lựa chọn khác, có thể một hoặc nhiều SA trong SA3 là duy nhất tới người gửi cụ thể. Một SA3 có thể được thiết lập lại hoặc nó có sự thay đổi khóa thông qua thao tác đổi khóa xảy ra thông qua SA2 (áp dụng cho một số nhóm nhỏ hơn).
Theo cách này mục đích để khởi tạo sử dụng SA1 để đảm bảo lấy các SA2 và SA3 từ KD về các thành viên. SA2 được sử dụng cho các thông điệp điều khiển được gửi bởi KD, trong khi SA3 được sử dụng cho thông điệp dữ liệu (chẳng hạn lưu lượng hoặc nội dung) từ người gửi tới người nhận. Đưa vào trong thông điệp điều khiển là các thông tin cập nhật hoặc thay thế trong SA3. Do đó chúng ta có thể nói rằng SA2 được sử dụng để cập nhật lại SA3, khi nó được tiên đoán trước sẽ có một vài người sử dụng SA2 so với SA3 (chẳng hạn: SA3 được sử dụng cho một khối lượng luồng dữ liệu media). Thuận theo cách tự nhiên, chính sách bảo mật của SA2 phải đủ mạnh bằng hoặc hơn so với SA3. Hai phần tùy chọn cuối cùng là khả năng sẵn sàng cho việc cập nhật SA2 khi có sự thay đổi. SA2 có thể được cập nhật thông qua SA1 một lần nữa (unicast), hoặc SA2 cũ có thể được sử dụng để cập nhật cho SA2 mới. Điều này trái với tùy chọn thực hiện theo [20], khi định nghĩa GSA phải đảm bảo cho các ứng dụng biến đổi trong phạm vi rộng.
Lưu ý rằng các ứng dụng cập nhật khóa xảy ra bên trong luồng dữ liệu (sử dụng SA3 để bảo vệ), định nghĩa GSA yêu cầu SA2 phải được khai báo là giá trị null (điều đó khác với việc không tồn tại). Trong một vài trường hợp ứng dụng chỉ đơn giản dạng PPV(Pay-per-view), tất cả các thông tin SA cần cho các session có thể được phân phối tại thời điểm đăng ký hoặc sự lựa chọn session (chẳng hạn thông qua SA1). Thay khóa và khởi tạo lại khóa có thể không cần thiết, vì vậy SA2 là null. Hầu hết các ứng dụng gắn việc thay đổi khởi tạo unicast với phân phối
Multicast để thay khóa. Để góp các nhóm với các khóa được thay đổi khi các thành viên có sự thay đổi, khi đó một SA2 cần thiết để khởi tạo lại SA3.